Date: Wed, 4 Jul 2018 11:13:03 -0400 From: Rich Felker <dalias@...c.org> To: Florian Weimer <fweimer@...hat.com> Cc: musl@...ts.openwall.com Subject: Re: arc4random/csprng On Wed, Jul 04, 2018 at 01:36:00PM +0200, Florian Weimer wrote: > On 07/03/2018 05:17 PM, Rich Felker wrote: > > >>But it's still quite common to do things with direct system calls, > >>particularly for setting up containers. > >> > >>I have not yet found a case which I couldn't solve with plain fork > >>(with handlers) and unshare, but that's not what everyone does > >>unfortunately. > > > >I agree you might need direct use of clone sometime for > >namespace/container stuff, but I don't think there's any way it can be > >made safe without careful consideration of what you do after the > >operation before a subsequent execve or _exit. I don't think it makes > >sense to design big machinery to support doing something that has > >deeper reasons it can't work, but this is probably partly a difference > >in philosophy between glibc and musl (see also: dlclose, lazy dtls, > >lazy tlsdesc, ...). > > I would suggest to keep at least the fork detection bit, even if you > do not reseed and deadlock or abort instead, because the duplicate > stream of random bits could be very hard to detect otherwise. I don't want, and I don't think others will want, musl to be unconditionally mmapping extra memory in every process for the sake of safely handling programs doing invalid/unsupported hacks. What might be acceptable is something like, at stirring time, doing: if (__syscall(SYS_gettid)!=self->tid) a_crash(); Another idea is adding to syscall.c (public syscall() function) something like: if (n==SYS_fork || n==SYS_clone) flag=1; and in the csprng: if (flag) a_crash(); or just: if (n==SYS_fork || n==SYS_clone) return __syscall_ret(-EINVAL); In any case, the public clone() function, which should be valid to use in a limited sense if we're offering it at all, should also be reviewed for safety (not specific to csprng issues) and for what properties we want to guarantee/support, like whether it's valid to do non-AS-safe stuff after a fork-like clone in a single-threaded process. The above flag idea may be a useful tool in this -- by actively storing knowledge that a type of fork/clone that leaves the process in an async signal context has taken place, we could trap a lot of UB in the child. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.