lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 20 Feb 2019 10:00:28 -0800
From:   Olof Johansson <>
To:     Peter Zijlstra <>
Cc:     Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        "H . Peter Anvin" <>,,
        Linux Kernel Mailing List <>
Subject: Re: [PATCH] x86/nmi: ratelimit unknown nmi logs

On Wed, Feb 20, 2019 at 12:59 AM Peter Zijlstra <> wrote:
> On Tue, Feb 19, 2019 at 05:48:36PM -0800, Olof Johansson wrote:
> > Getting notified of unknown NMIs is obviously important, but getting
> > notified on every single one, especially on larger systems with slow
> > (serial) console causes more harm than good when it's a known noisy
> > non-relevant event.
> >
> > So, let's ratelimit to avoid locking up the system.
> What kind of bonghit broken crap system is that?
> That is; this _really_ should not happen, and this is a bandaid, not
> fixing the cause.

Oh, I agree -- this shouldn't happen, and it's being debugged and fixed.

So, I'm not looking at this as a bandaid to the real problem, but
there's also no reason to DoS the system with prink when it does
occur. If you want to configure the system to panic on unknown NMI
there are already hooks for it.

I'm obviously happy to carry local patches for this, since it's a
temporary problem. But yet again, I don't see a reason to have the
kernel run off the rails for this condition.


Powered by blists - more mailing lists