linux-kernel - Re: [PATCH v13 01/21] KVM: x86: Introduce KVM_{G,S}ET_ONE

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: <aLD3yS6LQR7b55CR@intel.com>
Date: Fri, 29 Aug 2025 08:43:53 +0800
From: Chao Gao <chao.gao@...el.com>
To: Xiaoyao Li <xiaoyao.li@...el.com>
CC: <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <bp@...en8.de>,
	<dave.hansen@...ux.intel.com>, <hpa@...or.com>, <john.allen@....com>,
	<mingo@...hat.com>, <minipli@...ecurity.net>, <mlevitsk@...hat.com>,
	<pbonzini@...hat.com>, <rick.p.edgecombe@...el.com>, <seanjc@...gle.com>,
	<tglx@...utronix.de>, <weijiang.yang@...el.com>, <x86@...nel.org>,
	<xin@...or.com>
Subject: Re: [PATCH v13 01/21] KVM: x86: Introduce KVM_{G,S}ET_ONE_REG uAPIs
 support

On Thu, Aug 28, 2025 at 08:58:07PM +0800, Xiaoyao Li wrote:
>On 8/21/2025 9:30 PM, Chao Gao wrote:
>> From: Yang Weijiang <weijiang.yang@...el.com>
>> 
>> Enable KVM_{G,S}ET_ONE_REG uAPIs so that userspace can access HW MSR or
>> KVM synthetic MSR through it.
>> 
>> In CET KVM series [1], KVM "steals" an MSR from PV MSR space and access
>> it via KVM_{G,S}ET_MSRs uAPIs, but the approach pollutes PV MSR space
>> and hides the difference of synthetic MSRs and normal HW defined MSRs.
>> 
>> Now carve out a separate room in KVM-customized MSR address space for
>> synthetic MSRs. The synthetic MSRs are not exposed to userspace via
>> KVM_GET_MSR_INDEX_LIST, instead userspace complies with KVM's setup and
>> composes the uAPI params. KVM synthetic MSR indices start from 0 and
>> increase linearly. Userspace caller should tag MSR type correctly in
>> order to access intended HW or synthetic MSR.
>
>The old feedback[*] was to introduce support for SYNTHETIC registers instead
>of limiting it to MSR.

GUEST_SSP is a real register but not an MSR, so it's ok to treat it as a
synthetic MSR. But, it's probably inappropriate/inaccurate to call it a
synthetic register.

I think we need a clear definition for "synthetic register" to determine what
should be included in this category. "synthetic MSR" is clear - it refers to
something that isn't an MSR in hardware but is handled by KVM as an MSR.

That said, I'm still fine with renaming all "synthetic MSR" to "synthetic
register" in this series. :)

Sean, which do you prefer with fresh eyes?

If we make this change, I suppose KVM_x86_REG_TYPE_SIZE() should be dropped, as
we can't guarantee that the size will remain constant for the "synthetic
register" type, since it could be extended to include registers with different
sizes in the future.

>
>As in patch 09, it changes to name guest SSP as
>
>  #define KVM_SYNTHETIC_GUEST_SSP 0
>
>Nothing about MSR.
>
>[*] https://lore.kernel.org/all/ZmelpPm5YfGifhIj@google.com/
>

<snip>

>> +
>> +#define KVM_X86_REG_MSR(index)					\
>> +	KVM_X86_REG_ENCODE(KVM_X86_REG_TYPE_MSR, index)
>> +#define KVM_X86_REG_SYNTHETIC_MSR(index)			\
>> +	KVM_X86_REG_ENCODE(KVM_X86_REG_TYPE_SYNTHETIC_MSR, index)
>
>BTW, do we need to add some doc of the IDs, e.g., to
>
>4.68 KVM_SET_ONE_REG in Documentation/virt/kvm/api.rst ?

Yes. Will do.

<snip>
>> +struct kvm_x86_reg_id {
>> +	__u32 index;
>> +	__u8  type;
>> +	__u8  rsvd;
>> +	__u8  rsvd4:4;
>
>why naming it rsvd4? because it's 4-bit bit-field ?

I believe so. I copied this from here:

https://lore.kernel.org/kvm/aKS2WKBbZn6U1uqx@google.com/

I can rename rsvd and rsvd4 to rsvd1 and rsvd2 if that would be clearer.

>
>> +	__u8  size:4;
>> +	__u8  x86;
>> +};