4 ms·
Yep. The OpenBSD bootloader reads an entropy file from hard disk, mixes it with RDRAND from CPU (if available) and passes it to the Kernel. The Kernel starts a
by ben_bai 7y ago
Yep. The OpenBSD bootloader reads an entropy file from hard disk, mixes it with RDRAND from CPU (if available) and passes it to the Kernel.
The Kernel starts an ChaCha20 stream cipher with this supplied entropy while constantly mixing in timing entropy from devices.
This chipherstream supplies the Kernel with random data and once userland is up this is good enought and also used for /dev/random and /dev/urandom, which on OpenBSB is the same device(non blocking).
Now the fun part: When a userland process gets created it has a randomdata ELF segment that the Kernel fills and which is used as entropy for a new ChaCha20 stream, just for the application should it decide to call arc4random or use random data in any other way (like calling malloc or free, which on OpenBSD make heavy use of random data).
- throw0101a 7y ago> When a userland process gets created it has a randomdata ELF ... This is news to me. When did they add this (neat) functionality?
- notaplumber 7y agoIn 2012, first release 5.3 in 2013. Added by Matthew Dempsky. It was used for the per-shared object stack protector cookie extended for the per-function cookies required for RETGUARD. https://github.com/openbsd/src/blob/master/libexec/ld.so/SPECS.randomdata https://github.com/openbsd/src/blob/master/libexec/ld.so/SPE... https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html No other OS has this.
- geofft 7y agoLinux has an equivalent feature available through the "auxiliary vector," a set of data passed as the secret fourth parameter to main() / on the stack at program startup (after the secret third parameter, envp). http://man7.org/linux/man-pages/man3/getauxval.3.html http://man7.org/linux/man-pages/man3/getauxval.3.html and https://lwn.net/Articles/519085/ https://lwn.net/Articles/519085/ have a description of the auxiliary vector. One key, AT_RANDOM, contains 16 bytes (128 bits) of random data which libc uses for stack protector cookies. glibc uses this to implement stack and pointer protector cookies. (Unfortunately, glibc uses this data directly as stack and pointer protector cookies, instead of deriving something from it, which means it feels a little risky to use this to initialize a userspace PRNG. I guess you shouldn't be leaking cookies....) Linux added this in v2.6.29 (2009) in https://github.com/torvalds/linux/commit/f06295b4 https://github.com/torvalds/linux/commit/f06295b4 , and glibc in 2009 added support for using it if available to set up cookies (it previously read from /dev/urandom). That said, I don't really think the "we're the only OS" game is a game worth playing - if it's a security improvement, it's best if everyone has it, regardless of OS!
- wahern 7y agoThe .openbsd.randomdata ELF section is used for RETGUARD. arc4random(3) uses the getentropy(2) system call for seeding, and minherit(2)+MAP_INHERIT_ZERO for consistent, automatic reinitialization on fork. Interestingly, Linux provides 128 bits of random data on exec through the ELF auxiliary vector mechanism. (https://lwn.net/Articles/519085/ https://lwn.net/Articles/519085/) Between the disappearance of the sysctl(2) syscall and the addition of getrandom(2), it was the only way to acquire strong seed entropy without opening a file resource. EDIT: Which makes me curious how Linux filled AT_RANDOM for init(1) and other early boot time processes. But not curious enough to comb through old code...
- geofft 7y ago> EDIT: Which makes me curious how Linux filled AT_RANDOM for init(1) and other early boot time processes. But not curious enough to comb through old code... It uses get_random_bytes(), which is documented as "equivalent to a read from /dev/urandom." https://github.com/torvalds/linux/blob/v5.4/fs/binfmt_elf.c#L222 https://github.com/torvalds/linux/blob/v5.4/fs/binfmt_elf.c#...