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
| ||
|
Message-ID: <878rzkeq9f.ffs@tglx> Date: Sat, 25 Sep 2021 15:30:52 +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 Fri, Sep 24 2021 at 01:07, Thomas Gleixner wrote: > On Mon, Sep 13 2021 at 13:01, Sohil Mehta wrote: >> 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? Let's see how this works: task starts using UINTR. set UINTR_NOTIFACTION_VECTOR in MSR_IA32_UINTR_MISC So from that point on the User-Interrupt Notification Identification mechanism swallows the vector. Where this stops working is not limited to context switch. The wreckage comes from XSAVES: "After saving the user-interrupt state component, XSAVES clears UINV. (UINV is IA32_UINTR_MISC[39:32]; XSAVES does not modify the remainder of that MSR.)" So the problem is _not_ context switch. The problem is XSAVES and that can be issued even without a context switch. The obvious question is: What is the value of clearing UINV? Absolutely none. That notification vector cannot be used for anything else, so why would the OS be interested to see it ever? This is about user space interupts, right? UINV should be set _ONCE_ when CR4.UINTR is enabled and not be touched by XSAVES/XRSTORS at all. Any delivery of this vector to the OS should be considered a hardware bug. Thanks, tglx
Powered by blists - more mailing lists