linux-kernel - Re: [PATCH 19/19] KVM: x86: Enable supervisor IBT support for guest

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: <8d104ff6-5f31-5388-90f9-7dd6474440c9@intel.com>
Date:   Thu, 16 Jun 2022 23:56:17 +0800
From:   "Yang, Weijiang" <weijiang.yang@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "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 19/19] KVM: x86: Enable supervisor IBT support for guest


On 6/16/2022 7:19 PM, Peter Zijlstra wrote:
> On Thu, Jun 16, 2022 at 04:46:43AM -0400, Yang Weijiang wrote:
>> Mainline kernel now supports supervisor IBT for kernel code,
>> to make s-IBT work in guest(nested guest), pass through
>> MSR_IA32_S_CET to guest(nested guest) if host kernel and KVM
>> enabled IBT. Note, s-IBT can work independent to host xsaves
>> support because guest MSR_IA32_S_CET can be stored/loaded from
>> specific VMCS field.
>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index fe049d0e5ecc..c0118b33806a 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -1463,6 +1463,7 @@ static const u32 msrs_to_save_all[] = {
>>   	MSR_IA32_XFD, MSR_IA32_XFD_ERR,
>>   	MSR_IA32_XSS,
>>   	MSR_IA32_U_CET, MSR_IA32_PL3_SSP, MSR_KVM_GUEST_SSP,
>> +	MSR_IA32_S_CET,
>>   };
>
> So much like my local kvm/qemu hacks; this patch suffers the problem of
> not exposing S_SHSTK. What happens if a guest tries to use that?
With current solution, I think guest kernel will hit #GP while 
reading/writing PL0_SSP.
>
> Should we intercept and reject setting those bits or complete this patch
> and support full S_SHSTK? (with all the warts and horrors that entails)
>
> I don't think throwing this out in this half-finished state makes much
> sense (which is why I never much shared my hacks).

You reminded me to think over these cases even I don't have a solution now,

thank you!

>
>
>> @@ -11830,7 +11835,13 @@ int kvm_arch_hardware_setup(void *opaque)
>>   	/* Update CET features now as kvm_caps.supported_xss is finalized. */
>>   	if (!kvm_cet_user_supported()) {
>>   		kvm_cpu_cap_clear(X86_FEATURE_SHSTK);
>> -		kvm_cpu_cap_clear(X86_FEATURE_IBT);
>> +		/* If CET user bit is disabled due to cmdline option such as
>> +		 * noxsaves, but kernel IBT is on, this means we can expose
>> +		 * kernel IBT alone to guest since CET user mode msrs are not
>> +		 * passed through to guest.
>> +		 */
> Invalid multi-line comment style.
Oops, last minute change messed it up :-(
>
>> +		if (!cet_kernel_ibt_supported())
>> +			kvm_cpu_cap_clear(X86_FEATURE_IBT);