> On 12/18/2014 12:14 AM, Theo de Raadt wrote: > >> getentropy*.c: "cannot call abort() because some systems have unsafe > >> corefiles" > >> arc4random.c: "if(_rs_allocate(...) == -1) abort();" > >> > >> Am I missing any difference between the two cases? > >> (brain,cvsweb,google+gmane weren't any help) > > > > Policy. > > > > getentropy() should eventually be a lower level intrinsic. It is an > > emulation of a system call on another system (ie. OpenBSD). > > > > arc4random() is written on top of this, it is a standard library > > routine. > > > > For example. Say you wrote a replacement library that had open() and > > fopen(). The open should not fatally abort -- it's job is to return > > errors. That is firmly specified -- go read the open() manual page to > > get the picture. But the upper level function, what it does is less > > refined and more flexible implementation wise. > > > Agreed - I spent too much time trying to figure it out and too little > writing a clear question, sorry, let me retry :) > > Getentropy has no "internal" errors - if it fails it's the caller's > fault, otherwise it works 100% of the time, period. > Arc4random is designed to always work, and does so by being based on a > function that never fails; cvsweb mentions a dumb user could make it > (actually sysctl back then) fail with systrace, which used to be > ignored, now results in _getentropy_fail(), ie the system's equivalent > of a SIGKILL(*). > > So arc4random (used for ) always works, unless: > 1. getentropy fails => _getentropy_fail() > 2. mmap fails => abort() => "some systems have unsafe corefiles" > (I know #2 is unlikely to fail since it's a small amount of memory; > assume Murphy's law) > > Given that arc4random is the base for anything random in libressl, how > is abort potentially unsafe for #2 but not for #1? If someone can peek > at the dump they won't see the keystream but any data belonging to the > application will still be there - or not?
I explained that.
