openbsd/src/lib/libcrypto/arc4random, branch OPENBSD_6_3_BASEA mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_6_3_BASE2018-03-13T22:53:28+00:00ensure SYS_getrandom and GRND_NONBLOCK are both defined before using getrandom(2)2018-03-13T22:53:28+00:00bcook2018-03-13T22:53:28+00:00urn:sha1:302371947c6242ab9f7f993a57b4b413756adb5c
Based on discussion here https://github.com/libressl-portable/openbsd/pull/82
Suggested fix from jsing@
Switch Linux getrandom() usage to non-blocking mode, continuing to2017-04-29T18:43:31+00:00beck2017-04-29T18:43:31+00:00urn:sha1:06e58ee3d445df182278c56c23d0bf1aec820070
use fallback mechanims if unsuccessful.
The design of Linux getrandom is broken. It has an
uninitialized phase coupled with blocking behaviour, which
is unacceptable from within a library at boot time without
possible recovery.
ok deraadt@ jsing@
add iOS support for getentropy2016-09-03T15:24:09+00:00bcook2016-09-03T15:24:09+00:00urn:sha1:fc45c32b727123a9db48fbc11ff7d90f36199048
from Jacob Berkman, ok beck@
Update the link for the getentropy(2) manual to man.openbsd.org/2016-08-07T03:27:21+00:00tb2016-08-07T03:27:21+00:00urn:sha1:45a99457661a695d9e6070e26d9383b3a955a536
ok deraadt@
Tighten behavior of _rs_allocate failure for portable arc4random implementations.2016-06-30T12:19:51+00:00bcook2016-06-30T12:19:51+00:00urn:sha1:feaba99148498e3901e21567eef6244222c71431
In the event of a failure in _rs_allocate for rsx, we still have a reference to
freed memory for rs on return. Not a huge deal since we subsequently abort in
_rs_init, but it looks strange on its own.
ok deraadt@
Tighten behavior of _rs_allocate on Windows.2016-06-30T12:17:29+00:00bcook2016-06-30T12:17:29+00:00urn:sha1:04659cfbf6434208cea373c44b6482783a1a7299
For Windows, we are simply using calloc, which has two annoyances:
the memory has more permissions than needed by default, and it comes
from the process heap, which looks like a memory leak since this memory
is rightfully never freed.
This switches _rs_alloc on Windows to use VirtualAlloc, which restricts the
memory to READ|WRITE and keeps the memory out of the process heap.
ok deraadt@
fix typo in comment; ok beck2016-04-19T20:20:24+00:00tj2016-04-19T20:20:24+00:00urn:sha1:86631535ec5e92d1d055ad8b03986f6dc52cc4d7Calling clone(2) with CLONE_NEWPID yields multiple processes with pid=1.2016-01-04T02:04:56+00:00bcook2016-01-04T02:04:56+00:00urn:sha1:0f894628446dec0db2f00dac168dac6bcb7dd705
Work around this particular case by reseeding whenever pid=1, but as guenther@
notes, directly calling clone(2), and then forking to match another pid,
provides other ways to bypass new process detection on Linux.
Hopefully at some point Linux implements something like MAP_INHERIT_ZERO, and
does not invent a corresponding mechanism to subvert it.
Noted by Sebastian Krahmer and the opmsg team.
See http://stealth.openwall.net/crypto/randup.c for a test program.
ok beck@
unify files further2015-09-11T11:52:55+00:00deraadt2015-09-11T11:52:55+00:00urn:sha1:2a8f39dde4eb3fc8b492e8c665128c557ff500afunify versions, so they are easier to diff.2015-08-25T17:26:43+00:00deraadt2015-08-25T17:26:43+00:00urn:sha1:fc3d3d60211a42640c6c2273a1d4edf9901f1492