linux-kernel - Re: [PATCH] KVM: x86: Ignore MSR_AMD64_BU

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:   Thu, 5 Oct 2023 12:50:24 +0200
From:   "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Borislav Petkov <bp@...en8.de>, kvm@...r.kernel.org,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [PATCH] KVM: x86: Ignore MSR_AMD64_BU_CFG access

On 5.10.2023 02:10, Sean Christopherson wrote:
> On Mon, Oct 02, 2023, Maciej S. Szmigiero wrote:
>> On 26.09.2023 00:25, Tom Lendacky wrote:
>>>>> It's partially documented in various AMD BKDGs, however I couldn't find
>>>>> any definition for this particular bit (8) - other than that it is reserved.
>>>>
>>>> I found it as MSR_AMD64_BU_CFG for Model 16h, but that's Jaguar/Puma, not Zen1.
>>>> My guess is that Windows is trying to write this thing:
>>>>
>>>>     MSRC001_1023 [Table Walker Configuration] (Core::X86::Msr::TW_CFG)
>>>>     Read-write. Reset: 0000_0000_0000_0000h.
>>>>     _lthree0_core[3,1]; MSRC001_1023
>>>>
>>>>     Bits   Description
>>>>     63:50  Reserved.
>>>>     49     TwCfgCombineCr0Cd: combine CR0_CD for both threads of a core. Read-write. Reset: 0. Init: BIOS,1.
>>>>            1=The host Cr0_Cd values from the two threads are OR'd together and used by both threads.
>>>>     48:0   Reserved.
>>>>
>>>> Though that still doesn't explain bit 8...  Perhaps a chicken-bit related to yet
>>>> another speculation bug?
>>>>
>>>> Boris or Tom, any idea what Windows is doing?  I doubt it changes our options in
>>>> terms of "fixing" this in KVM, but having a somewhat accurate/helpful changelog
>>>> would be nice.
>>>
>>> It's definitely not related to a speculation bug, but I'm unsure what was
>>> told to Microsoft that has them performing that WRMSR. The patch does the
>>> proper thing, though, as a guest shouldn't be updating that setting.
>>>
>>> And TW_CFG is the proper name of that MSR for Zen.
>>
>> So, should I prepare v2 with MSR_AMD64_BU_CFG -> MSR_AMD64_TW_CFG change?
> 
> If we can get Paolo's attention, I'd like to get his thoughts on punting this
> to QEMU/userspace.  I'm worried that "handling" uarch specific MSRs in KVM is
> going to paint us into a corner and force KVM to check guest F/M/S someday, which
> I want to avoid at pretty much all costs.

We already do similar ignoring in KVM for MSR_AMD64_BU_CFG2, MSR_AMD64_DC_CFG
and MSR_F15H_EX_CFG, so doing this {BU_CFG2,TW_CFG} MSR filtering in QEMU would
be inconsistent with these.

But let's wait for Paolo's opinion then.

Thanks,
Maciej