linux-kernel - Re: [PATCH] x86 NMI: Be smarter about invoking panic() inside NMI handler.

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 29 Mar 2012 09:01:55 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	"Andrei E. Warkentin" <andrey.warkentin@...il.com>
Cc:	linux-kernel@...r.kernel.org, kgdb-bugreport@...ts.sourceforge.net,
	jason.wessel@...driver.com
Subject: Re: [PATCH] x86 NMI: Be smarter about invoking panic() inside NMI
 handler.

On Thu, Mar 29, 2012 at 03:19:56AM -0400, Andrei E. Warkentin wrote:
> Hi Don,
> 
> Thank you for your feedback!
> 
> 2012/3/27 Don Zickus <dzickus@...hat.com>:
> >
> > Hmm, if try_panic fails, then the cpu continues on executing code.  This
> > might further corrupt an already broken system.  So I don't think this
> > patch will work as is.
> >
> 
> I see what you are saying. I could make the argument that this kind
> of system corruption could occur anyway even if you did panic inside
> an IRQ context instead, but I would tend to agree that your proposed
> solution is much better than adding another panic interface.
> 
> > Perhaps instead of panic'ing in the NMI context, we use irq_work and panic
> > in an interrupt context instead.  We still get the system to stop (though
> > it might still execute some interrupts) and it will be out of the NMI
> > context.
> >
> > However, you will still run into a similar problem when in the
> > panic/reboot case we shutdown all the remote cpus and have them sitting in
> > a similar cpu_relax loop in the NMI context, while the panic'ing cpu
> > cleans things up.
> >
> 
> Sorry, could you clarify what you mean? How does this affect KDB usage?

I figured it would affect it the same way you described in your panic
scenario.  The machine panics and you are trying to break in with KDB.
The above issue just says the other cpus could block KDB from stopping all
the cpus much like your original issue.

But I will admit I didn't fully understand the original problem you were
trying to solve.

Cheers,
Don

> 
> A
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/