Re: [andrea@cpushare.com: Re: disable tsc with seccomp]

[daw@cs.berkeley.edu (David Wagner)]

Andrea Arcangeli  wrote:
>I take the opportunity of this reminder email, to ask one more question
>about the /dev/urandom device.  It would be really nice to have a good
>random number generator in CPUShare-seccomp mode, so I'm considering
>changing the CPUShare sell client to open /dev/urandom in O_RDONLY mode
>before firing seccomp.  However such a change means the urandom device
>driver will have to be secure in the way it creates the buffer [...]

What you suggest seems reasonable.  I guess I'm not qualified to take
any position on the specific question you asked.  However, I thought I'd
add a third option, that you could consider (though please don't consider
this as a criticism of any of your proposals).

The third option: When the seccomp-restricted program is spawned, the
parent could read 16 bytes from /dev/urandom, then communicate that
16-byte value to the seccomp-restricted child.  The child could then use
that as a seed to its own cryptographic pseudorandom generator, and could
generate all the pseudorandom values it needs starting from that seed,
without needing to interact with the OS or with /dev/urandom at all.
Expanding a short 16-byte seed into a long stretch of cryptographically
pseudorandom data only requires computation, so you can already support
this in today's seccomp, if I understand correctly how seccomp works.

Note that this option does not require SSL, and does not require
communicating the random bits across the Internet (which seems like a
questionable practice), so this is much safer than having someone on
the other side of the Internet pick your random numbers for you.