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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 24 Sep 2021 01:07:47 +0200 From: Thomas Gleixner <tglx@...utronix.de> To: Sohil Mehta <sohil.mehta@...el.com>, x86@...nel.org Cc: Sohil Mehta <sohil.mehta@...el.com>, Tony Luck <tony.luck@...el.com>, Dave Hansen <dave.hansen@...el.com>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, "H . Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>, Jens Axboe <axboe@...nel.dk>, Christian Brauner <christian@...uner.io>, Peter Zijlstra <peterz@...radead.org>, Shuah Khan <shuah@...nel.org>, Arnd Bergmann <arnd@...db.de>, Jonathan Corbet <corbet@....net>, Ashok Raj <ashok.raj@...el.com>, Jacob Pan <jacob.jun.pan@...ux.intel.com>, Gayatri Kammela <gayatri.kammela@...el.com>, Zeng Guang <guang.zeng@...el.com>, Dan Williams <dan.j.williams@...el.com>, Randy E Witt <randy.e.witt@...el.com>, Ravi V Shankar <ravi.v.shankar@...el.com>, Ramesh Thomas <ramesh.thomas@...el.com>, linux-api@...r.kernel.org, linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org Subject: Re: [RFC PATCH 05/13] x86/irq: Reserve a user IPI notification vector On Mon, Sep 13 2021 at 13:01, Sohil Mehta wrote: > A user interrupt notification vector is used on the receiver's cpu to > identify an interrupt as a user interrupt (and not a kernel interrupt). > Hardware uses the same notification vector to generate an IPI from a > sender's cpu core when the SENDUIPI instruction is executed. > > Typically, the kernel shouldn't receive an interrupt with this vector. > However, it is possible that the kernel might receive this vector. > > Scenario that can cause the spurious interrupt: > > Step cpu 0 (receiver task) cpu 1 (sender task) > ---- --------------------- ------------------- > 1 task is running > 2 executes SENDUIPI > 3 IPI sent > 4 context switched out > 5 IPI delivered > (kernel interrupt detected) > > A kernel interrupt can be detected, if a receiver task gets scheduled > out after the SENDUIPI-based IPI was sent but before the IPI was > delivered. What happens if the SENDUIPI is issued when the target task is not on the CPU? How is that any different from the above? > The kernel doesn't need to do anything in this case other than receiving > the interrupt and clearing the local APIC. The user interrupt is always > stored in the receiver's UPID before the IPI is generated. When the > receiver gets scheduled back the interrupt would be delivered based on > its UPID. So why on earth is that vector reaching the CPU at all? > +#ifdef CONFIG_X86_USER_INTERRUPTS > + seq_printf(p, "%*s: ", prec, "UIS"); No point in printing that when user interrupts are not available/enabled on the system. > + for_each_online_cpu(j) > + seq_printf(p, "%10u ", irq_stats(j)->uintr_spurious_count); > + seq_puts(p, " User-interrupt spurious event\n"); > #endif > return 0; > } > @@ -325,6 +331,33 @@ DEFINE_IDTENTRY_SYSVEC_SIMPLE(sysvec_kvm_posted_intr_nested_ipi) > } > #endif > > +#ifdef CONFIG_X86_USER_INTERRUPTS > +/* > + * Handler for UINTR_NOTIFICATION_VECTOR. > + * > + * The notification vector is used by the cpu to detect a User Interrupt. In > + * the typical usage, the cpu would handle this interrupt and clear the local > + * apic. > + * > + * However, it is possible that the kernel might receive this vector. This can > + * happen if the receiver thread was running when the interrupt was sent but it > + * got scheduled out before the interrupt was delivered. The kernel doesn't > + * need to do anything other than clearing the local APIC. A pending user > + * interrupt is always saved in the receiver's UPID which can be referenced > + * when the receiver gets scheduled back. > + * > + * If the kernel receives a storm of these, it could mean an issue with the > + * kernel's saving and restoring of the User Interrupt MSR state; Specifically, > + * the notification vector bits in the IA32_UINTR_MISC_MSR. Definitely well thought out hardware that. Thanks, tglx
Powered by blists - more mailing lists