linux-kernel - Re: [PATCH] x86/fpu/xstate: Fix XSTATE_WARN

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]

Date:   Wed, 28 Sep 2022 17:57:57 +0000
From:   Andrew Cooper <Andrew.Cooper3@...rix.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        Marek Marczykowski-Górecki 
        <marmarek@...isiblethingslab.com>
Subject: Re: [PATCH] x86/fpu/xstate: Fix XSTATE_WARN_ON() to emit relevant
 diagnostics

On 28/09/2022 17:27, Borislav Petkov wrote:
> On Wed, Aug 10, 2022 at 11:19:09PM +0100, Andrew Cooper wrote:
>> "XSAVE consistency problem" has been reported under Xen, but that's the extent
>> of my divination skills.
>>
>> Modify XSTATE_WARN_ON() to force the caller to provide relevant diagnostic
>> information, and modify each caller suitably.
>>
>> For check_xstate_against_struct(), this removes a double WARN() where one will
>> do perfectly fine.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@...rix.com>
>> ---
>> CC: Thomas Gleixner <tglx@...utronix.de>
>> CC: Ingo Molnar <mingo@...hat.com>
>> CC: Borislav Petkov <bp@...en8.de>
>> CC: Dave Hansen <dave.hansen@...ux.intel.com>
>> CC: x86@...nel.org
>> CC: Marek Marczykowski-Górecki <marmarek@...isiblethingslab.com>
>>
>> RFC: CC stable?  This has been wonky debugging for 7 years.
>>
>> Apparently "size 832 != kernel_size 0" so let the debugging continue...
> I've got a similar bug report from people running Linux guest on some
> other prop. HV. And I wanted to give them a debugging patch which dumps
> *all* the relevant data along the path of paranoid_xstate_size_valid(),
> the loop in there and xstate_calculate_size().
>
> Looking how you might need something like that too, how about you extend
> your patch to do that and have it being toggled on by a xstate=debug
> cmdline?
>
> It feels like this would be a useful thing to have with the gazillion of
> XSTATE features and dynamic buffer allocation...

So we've actually found and fixed the issue, but XSAVE and therefore
automatically gnarly.

https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c3bd0b83ea5b7c0da6542687436042eeea1e7909

There is no real hardware with XSAVEC but not XSAVES; the spec does try
to distinguish the two, and it's useful for virt to offer XSAVEC without
XSAVES.

CPUID.0xd[1].ebx is spec'd as the total size for XSAVES of all current
XCR0|XSS states.  This is known dodgy already for native, as it leaks
the current MSR_XSS setting into userspace.

I had written the logic originally to hide this dynamic field if XSAVES
wasn't enumerated, but Linux now uses it if XSAVEC is enumerated, to
cross-check what it can see elsewhere in the CPUID state.

I'm pretty sure things will break again when the host MSR_XSS becomes
non-zero, but I have no free time to spend on any of this in the first
place.

Ultimately, the issue here is that there is a privileged state leak, and
Linux is now relying on it for a sanity check.

~Andrew