[svsm-devel] [PATCH v4 09/15] x86/sev: Provide guest VMPL level to userspace

[Tom Lendacky]

On 5/27/24 08:51, Borislav Petkov wrote:
> On Wed, Apr 24, 2024 at 10:58:05AM -0500, Tom Lendacky wrote:
>> Requesting an attestation report from userspace involves providing the
>> VMPL level for the report. Currently any value from 0-3 is valid because
>> Linux enforces running at VMPL0.
>>
>> When an SVSM is present, though, Linux will not be running at VMPL0 and
>> only VMPL values starting at the VMPL level Linux is running at to 3 are
>> valid. In order to allow userspace to determine the minimum VMPL value
>> that can be supplied to an attestation report, create a sysfs entry that
>> can be used to retrieve the current VMPL level of Linux.
> 
> So what is the use case here: you create the attestation report *on* the
> running guest and as part of that, the script which does that should do
> 
> cat /sys/.../sev/vmpl
> 
> ?
> 
> But then sev-guest does some VMPL including into some report:
> 
> struct snp_report_req {
>          /* user data that should be included in the report */
>          __u8 user_data[SNP_REPORT_USER_DATA_SIZE];
> 
>          /* The vmpl level to be included in the report */
>          __u32 vmpl;
> 
> Why do you need this and can't use sev-guest?

The vmpl value is input from user-space.

The SNP spec allows the VMPL that is put in the attestation report to be 
numerically equal to or higher than the current VMPL (which is 
determined based on the VMPCK key that is used). So this is to let 
userspace know that it shouldn't request a value numerically smaller 
than what is reported in sysfs in order to avoid failure of the request.

> 
>> +static int __init sev_sysfs_init(void)
>> +{
>> +	struct kobject *sev_kobj;
>> +	int ret;
>> +
>> +	if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP))
>> +		return -ENODEV;
>> +
>> +	sev_kobj = kobject_create_and_add("sev", kernel_kobj);
> 
> In the main hierarchy?!
> 
> This is a x86 CPU thing, so if anything, it should be under
> /sys/devices/system/cpu/

I can move it there. Or what about creating a coco folder under 
/sys/kernel/? This would then create /sys/kernel/coco/sev/?

Thanks,
Tom

>