tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: regarding the changes to kernel entropy gathering



> 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.


Home | Main Index | Thread Index | Old Index