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:   Thu, 16 Jun 2022 23:06:03 +0800
From:   "Yang, Weijiang" <weijiang.yang@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     "seanjc@...gle.com" <seanjc@...gle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Subject: Re: [PATCH 00/19] Refresh queued CET virtualization series


On 6/16/2022 10:18 PM, Peter Zijlstra wrote:
> On Thu, Jun 16, 2022 at 12:21:20PM +0200, Paolo Bonzini wrote:
>> On 6/16/22 12:12, Peter Zijlstra wrote:
>>> Do I understand this right in that a host without X86_KERNEL_IBT cannot
>>> run a guest with X86_KERNEL_IBT on? That seems unfortunate, since that
>>> was exactly what I did while developing the X86_KERNEL_IBT patches.
>>>
>>> I'm thinking that if the hardware supports it, KVM should expose it,
>>> irrespective of the host kernel using it.
>> For IBT in particular, I think all processor state is only loaded and stored
>> at vmentry/vmexit (does not need XSAVES), so it should be feasible.
> That would be the S_CET stuff, yeah, that's VMCS managed. The U_CET
> stuff is all XSAVE though.

Thank you Peter and Paolo!

In this version, I referenced host kernel settings when expose 
X86_KERNEL_IBT to guest.

The reason would be _IF_ host, for whatever reason, disabled the IBT 
feature, exposing the

feature blindly to guest could be risking, e.g., hitting some issues 
host wants to mitigate.

The actual implementation depends on the agreement we got :-)

>
> But funny thing, CPUID doesn't enumerate {U,S}_CET separately. It *does*
> enumerate IBT and SS separately, but for each IBT/SS you have to
> implement both U and S.

Exactly, the CPUID enumeration could be a pain point for the KVM solution.

It makes {U,S}_CET feature control harder for guest.

>
> That was a problem with the first series, which only implemented support
> for U_CET while advertising IBT and SS (very much including S_CET), and
> still is a problem with this series because S_SS is missing while
> advertised.

KVM has problem advertising S_SS alone to guest when  U_CET(both SS and 
IBT) are

not available to guest. I would like to hear the voice from community on 
how to

make the features control straightforward and reasonable. Existing CPUID 
enumeration

cannot advertise {U, S}_SS and {U,S}_IBT well.

>