linux-kernel - Re: [PATCH 00/19] Refresh queued CET virtualization series

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:   Fri, 15 Jul 2022 23:04:37 +0800
From:   "Yang, Weijiang" <weijiang.yang@...el.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        rick.p.edgecombe@...el.com
Subject: Re: [PATCH 00/19] Refresh queued CET virtualization series


On 7/15/2022 3:36 AM, Sean Christopherson wrote:
> On Sat, Jun 18, 2022, Yang, Weijiang wrote:
>> On 6/16/2022 11:28 PM, Paolo Bonzini wrote:
>>> If you build with !X86_KERNEL_IBT, KVM can still rely on the FPU state
>>> for U_CET state, and S_CET is saved/restored via the VMCS independent of
>>> X86_KERNEL_IBT.
>> A fundamental question is, should KVM always honor host CET enablement
>> before expose the feature to guest? i.e., check X86_KERNEL_IBT and
>> X86_SHADOW_STACK.
> If there is a legitimate use case to NOT require host enablement and it's 100%
> safe to do so (within requiring hacks to the core kernel), then there's no hard
> requirement that says KVM can't virtualize a feature that's not used by the host.

Yeah, CET definitely can be virtualized without considering host usages, 
but to make things

easier, still back on some kind of host side support, e.g., xsaves.

>
> It's definitely uncommon; unless I'm forgetting features, LA57 is the only feature
> that KVM fully virtualizes (as opposed to emulates in software) without requiring
> host enablement.  Ah, and good ol' MPX, which is probably the best prior are since
> it shares the same XSAVE+VMCS for user+supervisor state management.  So more than
> one, but still not very many.

Speaking of MPX, is it really active in recent kernel? I can find little 
piece of code at native side,

instead, more code in KVM.

>
> But, requiring host "support" is the de facto standard largely because features
> tend to fall into one of three categories:
>
>    1. The feature is always available, i.e. doesn't have a software enable/disable
>       flag.
>
>    2. The feature isn't explicitly disabled in cpufeatures / x86_capability even
>       if it's not used by the host.  E.g. MONITOR/MWAIT comes to mind where the
>       host can be configured to not use MWAIT for idle, but it's still reported
>       as supported (and for that case, KVM does have to explicitly guard against
>       X86_BUG_MONITOR).
>
>    3. Require some amount of host support, e.g. exposing XSAVE without the kernel
>       knowing how to save/restore all that state wouldn't end well.

CET may fall into one of the three or combination of them :-), depending 
on the complexity

of the implementation.

>
> In other words, virtualizing a feature if it's disabled in the host is allowed,
> but it's rare because there just aren't many features where doing so is possible
> _and_ necessary.

I'm thinking of tweaking the patches to construct a safe yet flexible 
solution based on

a bunch of MSRs/CPUIDs/VMCS fields/XSAVES elements + a few host side 
constraints.

Thanks for the enlightenment!