Re: Logging a kernel message when blocking on entropy
On Tue, 22 Sep 2020, Taylor R Campbell wrote:
Date: Tue, 22 Sep 2020 13:07:04 +0300
From: Andreas Gustafsson
The following patch will cause a kernel message to be logged when a
process blocks on /dev/random or some other randomness API. It may
help some users befuddled by pkgsrc builds blocking on /dev/random,
and I'm finding it useful when testing changes aimed at fixing PR
55659.
OK to commit?
I think this is fine, but it should be rate-limited the same way other
messages in kern_entropy.c are rate-limited.
if (ratecheck(&lasttime, &interval))
printf("...");
Not sure if that's really necessary. There's a maximum of one message
per thread - ever, and even if every thread on the machine blocks, the
limit on number of threads stops you at 32k messages. As soon as one
thread un-blocks, nothing will ever block again, so that feels like a
hard limit.
Of course, since the rate-limiting code is already written, it wouldn't
hurt to use it. I'm just pointing out that there's a natural limit
inherent in the code!
:)
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Logging a kernel message when blocking on entropy
> Date: Tue, 22 Sep 2020 13:07:04 +0300
> From: Andreas Gustafsson
>
> The following patch will cause a kernel message to be logged when a
> process blocks on /dev/random or some other randomness API. It may
> help some users befuddled by pkgsrc builds blocking on /dev/random,
> and I'm finding it useful when testing changes aimed at fixing PR
> 55659.
>
> OK to commit?
I think this is fine, but it should be rate-limited the same way other
messages in kern_entropy.c are rate-limited.
if (ratecheck(&lasttime, &interval))
printf("...");
Re: Sample boot.cfg for upgraded systems (rndseed & friends)
David Brownlee writes: > What would people think of installing an original copy of the etc set > in /usr/share/examples/etc or similar - its 4.9M extracted and ~500K > compressed and the ability to compare what is on the system to what it > was shipped with would have saved me so much effort over the years :) I personally unpack etc and xetc to /usr/netbsd-etc via the INSTALL-NetBSD update script in etcmanage. I would not be super keen on adding a full etc by default, especially because then there's the issue of managing it for upgrades. But if it is unpacked someplace, and updated on updates, and old files removed on updates via postinstall fix, maybe. signature.asc Description: PGP signature
Re: Sample boot.cfg for upgraded systems (rndseed & friends)
On Tue, 22 Sep 2020 at 18:02, Jonathan A. Kollasch wrote: > > On Tue, Sep 22, 2020 at 05:53:49PM +0100, David Brownlee wrote: > > Should NetBSD be shipping a default boot.cfg in /usr/share/examples > > (*) - thinking primarily of people who have upgraded from earlier > > NetBSD versions. > > > > I was looking to add in rndseed & just generally sync with the latest > > version but there doesn't seem to be a default example shipped with > > the system > > > > /boot.cfg is already shipped as part of the 'etc' set, and is handled by > etcupdate(8) like any other configuration file. Ah, thanks, excellent... then I have a different question :-p What would people think of installing an original copy of the etc set in /usr/share/examples/etc or similar - its 4.9M extracted and ~500K compressed and the ability to compare what is on the system to what it was shipped with would have saved me so much effort over the years :) David
Re: Sample boot.cfg for upgraded systems (rndseed & friends)
On Tue, Sep 22, 2020 at 05:53:49PM +0100, David Brownlee wrote: > Should NetBSD be shipping a default boot.cfg in /usr/share/examples > (*) - thinking primarily of people who have upgraded from earlier > NetBSD versions. > > I was looking to add in rndseed & just generally sync with the latest > version but there doesn't seem to be a default example shipped with > the system > /boot.cfg is already shipped as part of the 'etc' set, and is handled by etcupdate(8) like any other configuration file.
Sample boot.cfg for upgraded systems (rndseed & friends)
Should NetBSD be shipping a default boot.cfg in /usr/share/examples (*) - thinking primarily of people who have upgraded from earlier NetBSD versions. I was looking to add in rndseed & just generally sync with the latest version but there doesn't seem to be a default example shipped with the system *: Or /usr/mdec, or /etc/... ? David
Re: Logging a kernel message when blocking on entropy
Andreas Gustafsson writes: > The following patch will cause a kernel message to be logged when a > process blocks on /dev/random or some other randomness API. It may > help some users befuddled by pkgsrc builds blocking on /dev/random, > and I'm finding it useful when testing changes aimed at fixing PR > 55659. I'm in favor. I have not dug in to the brave new entropy world. I'm sure it's better in many ways, but it also seems like people/systems that used to not end up blocked before now do, apparently because some sources that used to be considered ok (timing of events) no longer are. So I think people should be given clues - things appear a bit too difficult now. signature.asc Description: PGP signature
Re: Logging a kernel message when blocking on entropy
On Tue, 22 Sep 2020 at 12:35, Manuel Bouyer wrote: > > On Tue, Sep 22, 2020 at 02:31:50PM +0300, Andreas Gustafsson wrote: > > Manuel Bouyer wrote: > > > I'm not sure we want a user-triggerable kernel printf enabled by default. > > > This could be used to DOS the system (especially on serial consoles) > > > > You can already trigger kernel printfs as an unprivileged user. > > The first one that comes to mind is "sorry, pid %d was killed: > > orphaned traced process", but I'm sure there are many others. > > I think we should find and remove theses (or make them conditional) > instead of adding unconditional new ones Maybe a standard way of rate limiting such messages, including indicating how many were skipped due to rate limiting when the next one gets printed? David
Re: Logging a kernel message when blocking on entropy
On Tue, Sep 22, 2020 at 03:23:59PM +0300, Andreas Gustafsson wrote: > Manuel Bouyer wrote: > > > In -current, entropy does not run out. > > > > So, how can it block ? > > When there's too little entropy to begin with. Once you have > gathered enough, it unblocks, and never blocks again. > > This is assuming default settings. If you actually want entropy > to run out, you can do "sysctl -w kern.entropy.depletion=1", but > there's no good reason to ever do that outside of testing. > -- > Andreas Gustafsson, g...@gson.org On Tue, Sep 22, 2020 at 02:25:25PM +0200, Martin Husemann wrote: > On Tue, Sep 22, 2020 at 02:12:19PM +0200, Manuel Bouyer wrote: > > So, how can it block ? > > When the system never had enough entropy. > > I would consider this a bug in the setup of the system, but as of now we do > not deal with it at all during installation, and on systems that are not > installed (bootable images) it is even harder. > > Sysinst will complain about it soon (and offer options to help fix it). OK, so the printf should never happen when the system has been properly configured. In this case I have no objection. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Logging a kernel message when blocking on entropy
On Tue, Sep 22, 2020 at 02:12:19PM +0200, Manuel Bouyer wrote: > So, how can it block ? When the system never had enough entropy. I would consider this a bug in the setup of the system, but as of now we do not deal with it at all during installation, and on systems that are not installed (bootable images) it is even harder. Sysinst will complain about it soon (and offer options to help fix it). Martin
Re: Logging a kernel message when blocking on entropy
Manuel Bouyer wrote: > > In -current, entropy does not run out. > > So, how can it block ? When there's too little entropy to begin with. Once you have gathered enough, it unblocks, and never blocks again. This is assuming default settings. If you actually want entropy to run out, you can do "sysctl -w kern.entropy.depletion=1", but there's no good reason to ever do that outside of testing. -- Andreas Gustafsson, g...@gson.org
Re: Logging a kernel message when blocking on entropy
On Tue, Sep 22, 2020 at 03:05:34PM +0300, Andreas Gustafsson wrote: > Manuel Bouyer wrote: > > If you run a dd on /dev/random I guess the system will run out of > > entropy pretty fast. > > In -current, entropy does not run out. So, how can it block ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Logging a kernel message when blocking on entropy
Manuel Bouyer wrote: > If you run a dd on /dev/random I guess the system will run out of > entropy pretty fast. In -current, entropy does not run out. -- Andreas Gustafsson, g...@gson.org
Re: Logging a kernel message when blocking on entropy
On Tue, Sep 22, 2020 at 02:50:37PM +0300, Andreas Gustafsson wrote: > Manuel Bouyer wrote: > > I think we should find and remove theses (or make them conditional) > > instead of adding unconditional new ones > > It would already be conditional in the sense that it's only printed if > the system has no entropy. If a multi-user system is lacking entropy, > a user spamming the console about it is doing the administrator a > favor. If you run a dd on /dev/random I guess the system will run out of entropy pretty fast. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Logging a kernel message when blocking on entropy
Manuel Bouyer wrote: > I think we should find and remove theses (or make them conditional) > instead of adding unconditional new ones It would already be conditional in the sense that it's only printed if the system has no entropy. If a multi-user system is lacking entropy, a user spamming the console about it is doing the administrator a favor. -- Andreas Gustafsson, g...@gson.org
Re: Logging a kernel message when blocking on entropy
On Tue, Sep 22, 2020 at 02:31:50PM +0300, Andreas Gustafsson wrote: > Manuel Bouyer wrote: > > I'm not sure we want a user-triggerable kernel printf enabled by default. > > This could be used to DOS the system (especially on serial consoles) > > You can already trigger kernel printfs as an unprivileged user. > The first one that comes to mind is "sorry, pid %d was killed: > orphaned traced process", but I'm sure there are many others. I think we should find and remove theses (or make them conditional) instead of adding unconditional new ones -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Logging a kernel message when blocking on entropy
Manuel Bouyer wrote: > I'm not sure we want a user-triggerable kernel printf enabled by default. > This could be used to DOS the system (especially on serial consoles) You can already trigger kernel printfs as an unprivileged user. The first one that comes to mind is "sorry, pid %d was killed: orphaned traced process", but I'm sure there are many others. -- Andreas Gustafsson, g...@gson.org
Re: Logging a kernel message when blocking on entropy
On Tue, Sep 22, 2020 at 01:07:04PM +0300, Andreas Gustafsson wrote: > All, > > The following patch will cause a kernel message to be logged when a > process blocks on /dev/random or some other randomness API. It may > help some users befuddled by pkgsrc builds blocking on /dev/random, > and I'm finding it useful when testing changes aimed at fixing PR > 55659. > > OK to commit? I'm not sure we want a user-triggerable kernel printf enabled by default. This could be used to DOS the system (especially on serial consoles) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Logging a kernel message when blocking on entropy
All,
The following patch will cause a kernel message to be logged when a
process blocks on /dev/random or some other randomness API. It may
help some users befuddled by pkgsrc builds blocking on /dev/random,
and I'm finding it useful when testing changes aimed at fixing PR
55659.
OK to commit?
Index: src/sys/kern/kern_entropy.c
===
RCS file: /bracket/repo/src/sys/kern/kern_entropy.c,v
retrieving revision 1.23
diff -u -r1.23 kern_entropy.c
--- src/sys/kern/kern_entropy.c 14 Aug 2020 00:53:16 - 1.23
+++ src/sys/kern/kern_entropy.c 20 Sep 2020 13:53:46 -
@@ -1297,6 +1297,9 @@
/* Wait for some entropy to come in and try again. */
KASSERT(E->stage >= ENTROPY_WARM);
+ printf("entropy: pid %d (%s) blocking due to lack of entropy\n",
+ curproc->p_pid, curproc->p_comm);
+
if (ISSET(flags, ENTROPY_SIG)) {
error = cv_wait_sig(&E->cv, &E->lock);
if (error)
--
Andreas Gustafsson, g...@gson.org
