linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-coco@lists.linux.dev, svsm-devel@coconut-svsm.dev,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Michael Roth <michael.roth@amd.com>,
	Ashish Kalra <ashish.kalra@amd.com>
Subject: Re: [PATCH v4 09/15] x86/sev: Provide guest VMPL level to userspace
Date: Tue, 28 May 2024 16:08:35 -0500	[thread overview]
Message-ID: <e7c24be1-dbea-0efd-2661-b626fd655478@amd.com> (raw)
In-Reply-To: <20240527135101.GBZlSPxQ6iBSlMDefY@fat_crate.local>

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

> 

  reply	other threads:[~2024-05-28 21:08 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24 15:57 [PATCH v4 00/15] Provide SEV-SNP support for running under an SVSM Tom Lendacky
2024-04-24 15:57 ` [PATCH v4 01/15] x86/sev: Shorten snp_secrets_page_layout to snp_secrets_page Tom Lendacky
2024-04-25 13:30   ` Borislav Petkov
2024-04-24 15:57 ` [PATCH v4 02/15] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
2024-04-24 15:57 ` [PATCH v4 03/15] x86/sev: Make the VMPL0 checking more straight forward Tom Lendacky
2024-04-24 15:58 ` [PATCH v4 04/15] x86/sev: Check for the presence of an SVSM in the SNP Secrets page Tom Lendacky
2024-05-02  9:35   ` Borislav Petkov
2024-05-02 15:29     ` Tom Lendacky
2024-05-17 15:58       ` Borislav Petkov
2024-05-20 13:57         ` Tom Lendacky
2024-05-22 15:27           ` Borislav Petkov
2024-05-22 16:15             ` Tom Lendacky
2024-05-22 17:23               ` Borislav Petkov
2024-04-24 15:58 ` [PATCH v4 05/15] x86/sev: Use kernel provided SVSM Calling Areas Tom Lendacky
2024-05-03 10:34   ` Borislav Petkov
2024-05-06 10:09     ` Borislav Petkov
2024-05-06 13:14       ` Tom Lendacky
2024-05-06 14:14         ` Borislav Petkov
2024-05-08  8:05   ` Borislav Petkov
2024-05-08 19:13     ` Tom Lendacky
2024-05-08 19:40       ` Tom Lendacky
2024-05-08 19:58       ` Borislav Petkov
2024-05-08 20:09         ` Tom Lendacky
2024-05-17 19:23           ` Borislav Petkov
2024-04-24 15:58 ` [PATCH v4 06/15] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 Tom Lendacky
2024-05-22 18:24   ` Borislav Petkov
2024-05-22 21:14     ` Tom Lendacky
2024-05-27 12:01       ` Borislav Petkov
2024-04-24 15:58 ` [PATCH v4 07/15] x86/sev: Use the SVSM to create a vCPU when not in VMPL0 Tom Lendacky
2024-05-27 12:33   ` Borislav Petkov
2024-05-28 20:28     ` Tom Lendacky
2024-05-31 12:29       ` Borislav Petkov
2024-04-24 15:58 ` [PATCH v4 08/15] x86/sev: Provide SVSM discovery support Tom Lendacky
2024-05-27 13:10   ` Borislav Petkov
2024-05-28 20:57     ` Tom Lendacky
2024-05-31 12:48       ` Borislav Petkov
2024-04-24 15:58 ` [PATCH v4 09/15] x86/sev: Provide guest VMPL level to userspace Tom Lendacky
2024-05-27 13:51   ` Borislav Petkov
2024-05-28 21:08     ` Tom Lendacky [this message]
2024-05-30 17:06       ` Borislav Petkov
2024-04-24 15:58 ` [PATCH v4 10/15] virt: sev-guest: Choose the VMPCK key based on executing VMPL Tom Lendacky
2024-05-01 23:57   ` [svsm-devel] " Jacob Xu
2024-05-02 13:17     ` Tom Lendacky
2024-05-31 12:55   ` Borislav Petkov
2024-05-31 18:36     ` Tom Lendacky
2024-05-31 19:03       ` Borislav Petkov
2024-05-31 19:34         ` Tom Lendacky
2024-05-31 19:38           ` Borislav Petkov
2024-04-24 15:58 ` [PATCH v4 11/15] configfs-tsm: Allow the privlevel_floor attribute to be updated Tom Lendacky
2024-04-26 20:51   ` Dan Williams
2024-04-24 15:58 ` [PATCH v4 12/15] fs/configfs: Add a callback to determine attribute visibility Tom Lendacky
2024-04-26 21:48   ` Dan Williams
2024-04-29 13:26     ` Tom Lendacky
2024-04-24 15:58 ` [PATCH v4 13/15] x86/sev: Take advantage of configfs visibility support in TSM Tom Lendacky
2024-04-26 21:58   ` Dan Williams
2024-04-29 13:35     ` Tom Lendacky
2024-04-29 14:28       ` Tom Lendacky
2024-05-01 19:28         ` Dan Williams
2024-05-01  5:18   ` Kuppuswamy Sathyanarayanan
2024-05-01 20:15     ` Dan Williams
2024-05-02  3:40       ` Kuppuswamy Sathyanarayanan
2024-05-02 17:29         ` Dan Williams
2024-05-03 16:10   ` Kuppuswamy Sathyanarayanan
2024-04-24 15:58 ` [PATCH v4 14/15] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
2024-05-31 13:16   ` Borislav Petkov
2024-05-31 19:03     ` Tom Lendacky
2024-04-24 15:58 ` [PATCH v4 15/15] x86/sev: Allow non-VMPL0 execution when an SVSM is present Tom Lendacky
2024-05-03 11:37   ` [svsm-devel] " Jörg Rödel
2024-05-03 16:04     ` Borislav Petkov
2024-05-06  7:43       ` Jörg Rödel
2024-05-31 14:54   ` Borislav Petkov
2024-05-31 19:16     ` Tom Lendacky
2024-05-03 11:38 ` [svsm-devel] [PATCH v4 00/15] Provide SEV-SNP support for running under an SVSM Jörg Rödel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e7c24be1-dbea-0efd-2661-b626fd655478@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=svsm-devel@coconut-svsm.dev \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).