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: Thu, 23 Sep 2021 09:03:07 +0200 From: Peter Zijlstra <peterz@...radead.org> To: "Luck, Tony" <tony.luck@...el.com> Cc: "Yu, Fenghua" <fenghua.yu@...el.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>, "Hansen, Dave" <dave.hansen@...el.com>, Lu Baolu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>, Josh Poimboeuf <jpoimboe@...hat.com>, "Jiang, Dave" <dave.jiang@...el.com>, "Pan, Jacob jun" <jacob.jun.pan@...el.com>, "Raj, Ashok" <ashok.raj@...el.com>, "Shankar, Ravi V" <ravi.v.shankar@...el.com>, "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>, x86 <x86@...nel.org>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP On Wed, Sep 22, 2021 at 09:26:10PM +0000, Luck, Tony wrote: > >> > +static bool fixup_pasid_exception(void) > >> > +{ > >> > + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD)) > >> > + return false; > >> > + > >> > + return __fixup_pasid_exception(); > >> > +} > > > > That is, shouldn't the above at the very least decode the instruction > > causing the #GP and check it's this ENQCMD thing? > > It can't reliably do that because some other thread in the process may > have re-written the memory that regs->ip points at (bizarre case, but > I think Dave Hansen brought it up). I don't buy that argument, any cross modifying code gets to keep the pieces in that case. > So it would just add extra code, and still only be a hint. > > Without the check this sequence is possible: > > 1) Process binds an accelerator (so mm->pasid is set) > 2) Task in the process executes something other than ENQCMD that gets a #GP > 3) Kernel says "Oh, mm->pasid is set, I'll initialize the IA32_PASID MSR to see if that fixes it" > 4) Nope. Re-executing the instruction at step #2 just gives another #GP > 5) Kernel says "I already set IA32_PASID, so this must be something else ... do regular #GP actions" > > Now if the task catches the signal that results from step #5 and avoids termination, it will have > IA32_PASID set ... but to the right value should it go on to actually execute ENQCMD at some > future point. > > So the corner case from not knowing whether this #GP was from ENQCMD or not is harmless. And all that *really* should be a in a comment near there, because I'm 100% sure I'll get confused and wonder about that very same thing the next time I see that code.
Powered by blists - more mailing lists