linux-kernel - Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP

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: <3f97b77e-a609-997b-3be7-f44ff7312b0d@intel.com>
Date:   Tue, 28 Sep 2021 12:19:22 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        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>,
        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 4/8] x86/traps: Demand-populate PASID MSR via #GP

On 9/28/21 11:50 AM, Luck, Tony wrote:
> On Mon, Sep 27, 2021 at 04:51:25PM -0700, Dave Hansen wrote:
...
>> 1. Hide whether we need to write to real registers
>> 2. Hide whether we need to update the in-memory image
>> 3. Hide other FPU infrastructure like the TIF flag.
>> 4. Make the users deal with a *whole* state in the replace API
> 
> Is that difference just whether you need to save the
> state from registers to memory (for the "update" case)
> or not (for the "replace" case ... where you can ignore
> the current register, overwrite the whole per-feature
> xsave area and mark it to be restored to registers).
> 
> If so, just a "bool full" argument might do the trick?

I want to be able to hide the complexity of where the old state comes
from.  It might be in registers or it might be in memory or it might be
*neither*.  It's possible we're running with stale register state and a
current->...->xsave buffer that has XFEATURES&XFEATURE_FOO 0.

In that case, the "old" copy might be memcpy'd out of the init_task.
Or, for pkeys, we might build it ourselves with init_pkru_val.

> Also - you have a "tsk" argument in your pseudo code. Is
> this needed? Are there places where we need to perform
> these operations on something other than "current"?

Two cases come to mind:
1. Fork/clone where we are doing things to our child's XSAVE buffer
2. ptrace() where we are poking into another task's state

ptrace() goes for the *whole* buffer now.  I'm not sure it would need
this per-feature API.  I just call it out as something that we might
need in the future.

> pseudo-code:
> 
> void *begin_update_one_xsave_feature(enum xfeature xfeature, bool full)
> {
> 	void *addr;
> 
> 	BUG_ON(!(xsave->header.xcomp_bv & xfeature));
> 
> 	addr = __raw_xsave_addr(xsave, xfeature);
> 
> 	fpregs_lock();
> 
> 	if (full)
> 		return addr;

If the feature is marked as in the init state in the buffer
(XSTATE_BV[feature]==0), this addr *could* contain total garbage.  So,
we'd want to make sure that the memory contents have the init state
written before handing them back to the caller.  That's not strictly
required if the user is writing the whole thing, but it's the nice thing
to do.

> 	if (xfeature registers are "live")
> 		xsaves(xstate, 1 << xfeature);

One little note: I don't think we would necessarily need to do an XSAVES
here.  For PKRU, for instance, we could just do a rdpkru.

> 	return addr;
> }
> 
> void finish_update_one_xsave_feature(enum xfeature xfeature)
> {
> 	mark feature modified

I think we'd want to do this at the "begin" time.  Also, do you mean we
should set XSTATE_BV[feature]?

> 	set TIF bit

Since the XSAVE buffer was updated, it now contains the canonical FPU
state.  It may have diverged from the register state, thus we need to
set TIF_NEED_FPU_LOAD.

It's also worth noting that we *could*:

	xrstors(xstate, 1<<xfeature);

as well.  That would bring the registers back up to day and we could
keep TIF_NEED_FPU_LOAD==0.

> 	fpregs_unlock();
> }
> 
> -Tony
>