linux-kernel - Re: [RFC PATCH 11/13] x86/uintr: Introduce uintr

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: <875yug4eos.ffs@tglx>
Date:   Fri, 01 Oct 2021 23:29:07 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andy Lutomirski <luto@...nel.org>,
        Sohil Mehta <sohil.mehta@...el.com>,
        the arch/x86 maintainers <x86@...nel.org>
Cc:     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>, Jens Axboe <axboe@...nel.dk>,
        Christian Brauner <christian@...uner.io>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Shuah Khan <shuah@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Jonathan Corbet <corbet@....net>,
        Raj Ashok <ashok.raj@...el.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Gayatri Kammela <gayatri.kammela@...el.com>,
        Zeng Guang <guang.zeng@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        Randy E Witt <randy.e.witt@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        Ramesh Thomas <ramesh.thomas@...el.com>,
        Linux API <linux-api@...r.kernel.org>,
        linux-arch@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH 11/13] x86/uintr: Introduce uintr_wait() syscall

On Fri, Oct 01 2021 at 08:13, Andy Lutomirski wrote:

> On Fri, Oct 1, 2021, at 2:56 AM, Thomas Gleixner wrote:
>> On Thu, Sep 30 2021 at 21:41, Andy Lutomirski wrote:
>>> On Thu, Sep 30, 2021, at 5:01 PM, Thomas Gleixner wrote:
>>
>>> Now that I read the docs some more, I'm seriously concerned about this
>>> XSAVE design.  XSAVES with UINTR is destructive -- it clears UINV.  If
>>> we actually use this, then the whole last_cpu "preserve the state in
>>> registers" optimization goes out the window.  So does anything that
>>> happens to assume that merely saving the state doesn't destroy it on
>>> respectable modern CPUs XRSTORS will #GP if you XRSTORS twice, which
>>> makes me nervous and would need a serious audit of our XRSTORS paths.
>>
>> I have no idea what you are fantasizing about. You can XRSTORS five
>> times in a row as long as your XSTATE memory image is correct.
>
> I'm just reading TFM, which is some kind of dystopian fantasy.
>
> 11.8.2.4 XRSTORS
>
> Before restoring the user-interrupt state component, XRSTORS verifies
> that UINV is 0. If it is not, XRSTORS causes a general-protection
> fault (#GP) before loading any part of the user-interrupt state
> component. (UINV is IA32_UINTR_MISC[39:32]; XRSTORS does not check the
> contents of the remainder of that MSR.)

Duh. I was staring at the SDM and searching for a hint. Stupid me!

> So if UINV is set in the memory image and you XRSTORS five times in a
> row, the first one will work assuming UINV was zero.  The second one
> will #GP.

Yes. I can see what you mean now :)

> 11.8.2.3 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 if we're running a UPID-enabled user task and we switch to a kernel
> thread, we do XSAVES and UINV is cleared.  Then we switch back to the
> same task and don't do XRSTORS (or otherwise write IA32_UINTR_MISC)
> and UINV is still clear.

Yes, that has to be mopped up on the way to user space.

> And we had better clear UINV when running a kernel thread because the
> UPID might get freed or the kernel thread might do some CPL3
> shenanigans (via EFI, perhaps? I don't know if any firmwares actually
> do this).

Right. That's what happens already with the current pile.

> So all this seems to put UINV into the "independent" category of
> feature along with LBR.  And the 512-byte wastes from extra copies of
> the legacy area and the loss of the XMODIFIED optimization will just
> be collateral damage.

So we'd end up with two XSAVES on context switch. We can simply do:

        XSAVES();
        fpu.state.xtsate.uintr.uinv = 0;

which allows to do as many XRSTORS in a row as we want. Only the final
one on the way to user space will have to restore the real vector if the
register state is not valid:

       if (fpu_state_valid()) {
            if (needs_uinv(current)
               wrmsrl(UINV, vector);
       } else {
            if (needs_uinv(current)
               fpu.state.xtsate.uintr.uinv = vector;
            XRSTORS();
       }

Hmm?

Thanks,

        tglx