linux-kernel - Re: [PATCH v2 1/7] KVM:VMX: Define CET VMCS fields and bits

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: <4d9a5393-163b-f32a-4657-cec54093ee88@redhat.com>
Date:   Tue, 29 Jan 2019 16:19:34 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Yang Weijiang <weijiang.yang@...el.com>
Cc:     rkrcmar@...hat.com, sean.j.christopherson@...el.com,
        jmattson@...gle.com, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, mst@...hat.com, yu-cheng.yu@...el.com,
        yi.z.zhang@...el.com, hjl.tools@...il.com,
        Zhang Yi Z <yi.z.zhang@...ux.intel.com>
Subject: Re: [PATCH v2 1/7] KVM:VMX: Define CET VMCS fields and bits

On 28/01/19 11:33, Yang Weijiang wrote:
>> There is no code in this series to pass these fields to and from
>> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and
>> PL3_SSP across context switches.
>>
> The kernel consumes these MSRs, please see kernel CET patch:
> https://lkml.org/lkml/fancy/2018/11/20/225

Still, even if the kernel saves these fields across context switch in
XSAVE areas, KVM must support accesses to the MSRs from userspace, for
example in order to perform live migration.

For example, when reading/writing these in kvm_set_msr or
kvm_get_msr_common, you would have to do a read/write from the host
MSRs.  You also have to put kvm_load_guest_fpu/kvm_put_guest_fpu calls
in __msr_io.

Thanks,

Paolo

>> In addition, PL1_SSP and PL2_SSP should be supported even if the guest
>> doesn't use them.  It makes sense to avoid intercepting them, but they
>> should still be supported and switched (possibly only if nonzero).
>>
>> Am I missing something, for example a dependency on host CET support?
>> If not, how was this series tested?
>>
> The guest CET feature is tested with kernel CET patches on internal
> virtual platform.
>