[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b50a822d-e9f3-58b2-7797-be5de0ee4626@amd.com>
Date: Sat, 27 Jan 2024 09:43:01 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: Dionna Amalie Glaze <dionnaglaze@...gle.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Dan Williams <dan.j.williams@...el.com>, Michael Roth
<michael.roth@....com>, Ashish Kalra <ashish.kalra@....com>
Subject: Re: [PATCH 08/11] x86/sev: Provide guest VMPL level to userspace
On 1/26/24 19:06, Dionna Amalie Glaze wrote:
> On Fri, Jan 26, 2024 at 2:19 PM Tom Lendacky <thomas.lendacky@....com> 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.
>
> Is this not the intended meaning of privlevel_floor in
> /sys/kernel/config/tsm/report/$report0/privlevel_floor?
Hmmm... possibly. But that would make someone using the ioctl() (which is
still available) have to use the config-tsm support to get the value. If
the overall consensus is not to have a sysfs entry, I'll remove it, but it
could be useful beyond just attestation.
Your comment does make me realize that I did miss changing privlevel_floor
for the TSM support. I need to set privlevel_floor to the current VMPL level.
Thanks,
Tom
>
Powered by blists - more mailing lists