On Tue, 29 Sep 2020 15:03:59 +0300, Andreas Gustafsson wrote:
> Hauke Fath wrote:
>> I have seen kernel subsystems spam the console to the point of making
>> it unusable, which can get quite awkward on production machines.
>
> I have already explained why I believe it's not a relevant scenario
>
Hauke Fath wrote:
> On Tue, 29 Sep 2020 11:09:25 +0300, Andreas Gustafsson wrote:
> > I have now committed the code to log the message, without rate
> > limiting. If a consensus should arise that rate limiting the message
> > is a good idea, the code to do that should be committed by someone in
>
On Tue, 29 Sep 2020 11:09:25 +0300, Andreas Gustafsson wrote:
> I have now committed the code to log the message, without rate
> limiting. If a consensus should arise that rate limiting the message
> is a good idea, the code to do that should be committed by someone in
> favor of it.
I have seen
I have now committed the code to log the message, without rate
limiting. If a consensus should arise that rate limiting the message
is a good idea, the code to do that should be committed by someone in
favor of it.
--
Andreas Gustafsson, g...@gson.org
nia wrote:
> Unless you buy one of the snake oil devices Mr. Gustafsson sells, of
> course.
The devices you call "snake oil" and me pushing for NetBSD to stop
generating predictable keys are both aspects of me working to address
entropy related vulnerabilities ever since recognizing them as a majo
nia wrote:
> On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote:
> > OK, so the printf should never happen when the system has been properly
> > configured. In this case I have no objection.
>
> No, it will happen frequently in VMs and on non-recent-x86 hardware.
The cases of processes
mar...@duskware.de (Martin Husemann) writes:
>On all of these it *still* is a setup error that needs to be avoided.
Every VM is installed manually by someone rolling dice so that such
setup errors cannot occur.
--
--
Michael van Elst
Internet: mlel...@serpens.de
On Thu, Sep 24, 2020 at 06:37:43AM +, nia wrote:
> On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote:
> > OK, so the printf should never happen when the system has been properly
> > configured. In this case I have no objection.
>
> No, it will happen frequently in VMs and on non-re
On Thu, Sep 24, 2020 at 06:37:43AM +, nia wrote:
> On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote:
> > OK, so the printf should never happen when the system has been properly
> > configured. In this case I have no objection.
>
> No, it will happen frequently in VMs and on non-re
On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote:
> OK, so the printf should never happen when the system has been properly
> configured. In this case I have no objection.
No, it will happen frequently in VMs and on non-recent-x86 hardware.
Taylor R Campbell wrote:
> 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("...");
I would prefer them not to be rate limited. Repeated mess
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 blocki
> 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
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 f
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 conso
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.
>
> Thi
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 (bootabl
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 "
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'exp
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
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 ha
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 co
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 unprivi
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:
orp
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 f
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?
26 matches
Mail list logo
