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 16:22:35 -0700 From: "Luck, Tony" <tony.luck@...el.com> To: Andy Lutomirski <luto@...nel.org> Cc: Fenghua Yu <fenghua.yu@...el.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, "Peter Zijlstra (Intel)" <peterz@...radead.org>, Dave Hansen <dave.hansen@...el.com>, Lu Baolu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>, Josh Poimboeuf <jpoimboe@...hat.com>, Dave Jiang <dave.jiang@...el.com>, Jacob Jun Pan <jacob.jun.pan@...el.com>, Raj Ashok <ashok.raj@...el.com>, "Shankar, Ravi V" <ravi.v.shankar@...el.com>, iommu@...ts.linux-foundation.org, the arch/x86 maintainers <x86@...nel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting On Thu, Sep 23, 2021 at 04:09:18PM -0700, Andy Lutomirski wrote: > On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote: > I think this is unnecessarily complicated because it's buying in to the > existing ISA misconception that PASID has anything to do with a task. > A PASID belongs to an mm, full stop. Now the ISA is nasty and we have > tasks that have *noticed* that their mm has a PASID and tasks that have > not noticed this fact, but that should be irrelevant to essentially > everything except the fault handler. > > So just refcount the thing the obvious way: take a reference when you > stick the PASID in the mm_struct and drop the reference in __mmdrop(). > Problem solved. You could probably drop it more aggressively in > __mmput(), and the comment explaining why is left as an exercise to the > reader -- if a kernel thread starts doing ENQCMD, we have worse things > to worry about :) That doesn't match well with the non-x86 usage of PASIDs. The code there bumps the reference count on each device bind, and decrements on each device unbind. If we don't keep a reference count for each task that has IA32_PASID set up we could have this sequence 1) Process binds to a PASID capable device 2) Task uses ENQCMD, so PASID MSR is set up. 3) Process unbinds the device, reference count on PASID goes to zero. PASID is freed. PASID is reallocated to another task. 4) Task from step #2 uses ENQCMD to submit a descriptor and device now processes virtual addresses based on mappings in the new task. Now you might say that at step 3 we need to hunt down all the tasks that have PASID enabled and disabled ... but that's the same painful code that we avoided when we said that we would not make Linux hand out a PASID to all existing tasks in a process on the first bind operation. -Tony
Powered by blists - more mailing lists