Re: regarding the changes to kernel entropy gathering

[matthew sporleder <msporleder%gmail.com@localhost>]

> On Apr 6, 2021, at 8:09 AM, Taylor R Campbell <riastradh%netbsd.org@localhost> wrote:
> 
> 
>> Date: Mon, 05 Apr 2021 10:58:58 +0700
>> From: Robert Elz <kre%munnari.OZ.AU@localhost>
>> I understand that some people desire highly secure systems (I'm not
>> convinced that anyone running NetBSD can really justify that desire,
>> but that's beside the point) and that's fine - make the system be able
>> to be as secure as possible, just don't require me to enable it, and
>> don't make it impossible or even difficuly to disable it - and allow
>> some kind of middle ground, just just "perfectly secure" and "hopeless".
> 
> The main issue that hits people is that the traditional mechanism by
> which the OS reports a potential security problem with entropy is for
> it to make applications silently hang -- and the issue is getting
> worse now that getrandom() is more widely used, e.g. in Python when
> you do `import multiprocessing'.
> 
> Based on experience over the past year with a meaningful criterion for
> _detecting_ potential problems, I don't think that's a useful
> mechanism for _reporting_ them, which is why I added several other
> mechanisms -- a line in the /etc/security report, an `entropy' knob in
> /etc/rc.conf to wait or fail to single-user (default: neither) -- and
> proposed to remove the blocking behaviour of getrandom() in favour of
> focusing on feedback in system integration:
> 
> https://mail-index.netbsd.org/tech-userlevel/2021/01/11/msg012807.html
> 
> (main discussion after all the noise starts here:
> https://mail-index.netbsd.org/tech-userlevel/2021/01/15/msg012846.html)
> 
> But I ran out of steam to continue the discussion at the time.


Is the issue gaw saw exclusive to xen first boots?  Are there other ways to end up in his situation?