linux-kernel - Re: [PATCH v3 00/27] Enable FRED with KVM VMX

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: <035769d2-e9ed-4bd4-86d0-6a4c011d07aa@zytor.com>
Date: Tue, 25 Feb 2025 10:48:24 -0800
From: Xin Li <xin@...or.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, Chao Gao <chao.gao@...el.com>,
        pbonzini@...hat.com, corbet@....net, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        x86@...nel.org, hpa@...or.com, luto@...nel.org, peterz@...radead.org,
        andrew.cooper3@...rix.com
Subject: Re: [PATCH v3 00/27] Enable FRED with KVM VMX

On 2/25/2025 9:35 AM, Sean Christopherson wrote:
> On Tue, Feb 25, 2025, Xin Li wrote:
>> On 2/25/2025 7:24 AM, Sean Christopherson wrote:
>>> On Tue, Feb 18, 2025, Xin Li wrote:
>>>> On 9/30/2024 10:00 PM, Xin Li (Intel) wrote:
>>>> While I'm waiting for the CET patches for native Linux and KVM to be
>>>> upstreamed, do you think if it's worth it for you to take the cleanup
>>>> and some of the preparation patches first?
>>>
>>> Yes, definitely.  I'll go through the series and see what I can grab now.
>>
>> I planned to do a rebase and fix the conflicts due to the reordering.
>> But I'm more than happy you do a first round.
> 
> For now, I'm only going to grab these:
> 
>    KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM
>    KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
>    KVM: x86: Use a dedicated flow for queueing re-injected exceptions
> 
> and the WRMSRNS patch.  I'll post (and apply, if it looks good) the entry/exit
> pairs patch separately.
> 
> Easiest thing would be to rebase when all of those hit kvm-x86/next.

Excellent!


> 
>> BTW, if you plan to take
>> 	KVM: VMX: Virtualize nested exception tracking
> 
> I'm not planning on grabbing this in advance of the FRED series, especially if
> it's adding new uAPI.  The code doesn't need to exist without FRED, and doesn't
> really make much sense to readers without the context of FRED.

Sounds reasonable.

> 
>>>> Top of my mind are:
>>>>       KVM: x86: Use a dedicated flow for queueing re-injected exceptions
>>>>       KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
>>>>       KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM
> 
> As above, I'll grab these now.
> 
>>>>       KVM: nVMX: Add a prerequisite to existence of VMCS fields
>>>>       KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros
> 
> Unless there's a really, really good reason to add precise checking, I strongly
> prefer to skip these entirely.
> 

They are to make kvm-unit-tests happy, as if we have a ground rule, it's
clear that we don't need them.

They can be used to detect whether an OS is running on a VMM or bare
metal, but do we really care the difference? -- We probably care if we
live in a virtual reality ;-)

>>>>
>>>> Then specially, the nested exception tracking patch seems a good one as
>>>> Chao Gao suggested to decouple the nested tracking from FRED:
>>>>       KVM: VMX: Virtualize nested exception tracking
>>>>
>>>> Lastly the patches to add support for the secondary VM exit controls might
>>>> go in early as well:
>>>>       KVM: VMX: Add support for the secondary VM exit controls
>>>>       KVM: nVMX: Add support for the secondary VM exit controls
> 
> Unless there's another feature on the horizon that depends on secondary exit controls,
> (and y'all will be posted patches soon), I'd prefer just grab these in the FRED
> series.  With the pairs check prep work out of the way, adding support for the
> new controls should be very straightforward, and shouldn't conflict with anything.

NP.

Thanks!
     Xin