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
| ||
|
Date: Wed, 13 Jun 2018 11:57:21 +0200 (CEST) From: Thomas Gleixner <tglx@...utronix.de> To: Julien Thierry <julien.thierry@....com> cc: Peter Zijlstra <peterz@...radead.org>, Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>, Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi.kleen@...el.com>, Ashok Raj <ashok.raj@...el.com>, Borislav Petkov <bp@...e.de>, Tony Luck <tony.luck@...el.com>, "Ravi V. Shankar" <ravi.v.shankar@...el.com>, x86@...nel.org, sparclinux@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org, Jacob Pan <jacob.jun.pan@...el.com>, Daniel Lezcano <daniel.lezcano@...aro.org>, Andrew Morton <akpm@...ux-foundation.org>, "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>, Randy Dunlap <rdunlap@...radead.org>, Masami Hiramatsu <mhiramat@...nel.org>, Marc Zyngier <marc.zyngier@....com>, Bartosz Golaszewski <brgl@...ev.pl>, Doug Berger <opendmb@...il.com>, Palmer Dabbelt <palmer@...ive.com>, iommu@...ts.linux-foundation.org Subject: Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI On Wed, 13 Jun 2018, Julien Thierry wrote: > On 13/06/18 10:20, Thomas Gleixner wrote: > > Adding NMI delivery support at low level architecture irq chip level is > > perfectly fine, but the exposure of that needs to be restricted very > > much. Adding it to the generic interrupt control interfaces is not going to > > happen. That's doomed to begin with and a complete abuse of the interface > > as the handler can not ever be used for that. > > > > Understood, however the need would be to provide a way for a driver to request > an interrupt to be delivered as an NMI (if irqchip supports it). s/driver/specialized code written by people who know what they are doing/ > But from your response this would be out of the question (in the > interrupt/irq/irqchip definitions). Adding some magic to the irq chip is fine, because that's where the low level integration needs to be done, but exposing it through the generic interrupt subsystem is a NONO for obvious reasons. > Or somehow the concerned irqchip informs the arch it supports NMI delivery and > it is up to the interested drivers to query the arch whether NMI delivery is > supported by the system? Yes, we need some infrastructure for that, but that needs to be separate and with very limited exposure. Thanks, tglx
Powered by blists - more mailing lists