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.
Signed-off-by: Tom Lendacky <[email protected]>
---
arch/x86/kernel/sev.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 69a756781d90..8edf7362136b 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2507,3 +2507,40 @@ void __init snp_remap_svsm_ca(void)
/* Update the CAA to a proper kernel address */
boot_svsm_caa = &boot_svsm_ca_page;
}
+
+static ssize_t vmpl_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return sysfs_emit(buf, "%d\n", vmpl);
+}
+
+static struct kobj_attribute vmpl_attr = __ATTR_RO(vmpl);
+
+static struct attribute *vmpl_attrs[] = {
+ &vmpl_attr.attr,
+ NULL
+};
+
+static struct attribute_group sev_attr_group = {
+ .attrs = vmpl_attrs,
+};
+
+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);
+ if (!sev_kobj)
+ return -ENOMEM;
+
+ ret = sysfs_create_group(sev_kobj, &sev_attr_group);
+ if (ret)
+ kobject_put(sev_kobj);
+
+ return ret;
+}
+arch_initcall(sev_sysfs_init);
--
2.43.2
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?
> +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/
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
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
>
On May 28, 2024 11:08:35 PM GMT+02:00, Tom Lendacky <[email protected]> wrote:
>I can move it there. Or what about creating a coco folder under /sys/kernel/? This would then create /sys/kernel/coco/sev/?
>
Sysfs hierarchy is special - can't just add stuff willy nilly. This doc hints at that:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/sysfs.rst
And then those things get documented here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI
and supported forever and ever until the end of time.
So the usage needs to be precisely documented and weighed whether we really need it...
Thx.
--
Sent from a small device: formatting sucks and brevity is inevitable.