linux-kernel - Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E39A5DE2-5615-41FF-9953-4F4C4E8499D8@amacapital.net>
Date:   Mon, 15 Jun 2020 14:18:39 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     "Yu, Fenghua" <fenghua.yu@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        H Peter Anvin <hpa@...or.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        Frederic Barrat <fbarrat@...ux.ibm.com>,
        Andrew Donnellan <ajd@...ux.ibm.com>,
        Felix Kuehling <Felix.Kuehling@....com>,
        Joerg Roedel <joro@...tes.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
        "Mehta, Sohil" <sohil.mehta@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        x86 <x86@...nel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        amd-gfx <amd-gfx@...ts.freedesktop.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID



> On Jun 15, 2020, at 1:56 PM, Luck, Tony <tony.luck@...el.com> wrote:
> 
> 
>> 
>> Are we planning to keep PASID live once a task has used it once or are we going to swap it lazily?  If the latter, a percpu variable might be better.
> 
> Current plan is "touch it once and the task owns it until exit(2)"
> 
> Maybe someday in the future when we have data on how applications
> actually use accelerators we could look at something more complex
> if usage patterns look like it would be beneficial.
> 
> 

So what’s the RDMSR for?  Surely you
have some state somewhere that says “this task has a PASID.”  Can’t you just make sure that stays in sync with the MSR?  Then, on #GP, if the task already has a PASID, you know the MSR is set.