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]
Date: Tue, 16 Apr 2024 10:17:33 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Dan Williams <dan.j.williams@...el.com>, linux-kernel@...r.kernel.org,
 x86@...nel.org, linux-coco@...ts.linux.dev, svsm-devel@...onut-svsm.dev
Cc: 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>, Michael Roth <michael.roth@....com>,
 Ashish Kalra <ashish.kalra@....com>
Subject: Re: [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on
 executing VMPL

On 4/15/24 23:54, Dan Williams wrote:
> Hey, Tom, came looking to review the tsm_report changes and noticed
> this...
> 
> Tom Lendacky wrote:
>> Currently, the sev-guest driver uses the vmpck-0 key by default. When an
>> SVSM is present the kernel is running at a VMPL other than 0 and the
>> vmpck-0 key is no longer available. So choose the vmpck key based on the
>> active VMPL level.
> 
> The module parameter is not mentioned in the changelog. Is it not
> sufficient to always use snp_get_vmpl(), and if not should there be some
> documentation about when to specify vmpck_id?

It is possible to encounter an issue that causes the vmpck key to be 
cleared. In that situation, the guest is allowed to use a vmpck key 
associated with a lower VMPL. For that reason, the module parameter was 
added to the driver when it was initially created.

I can update the changelog to mention this.

Note that as long as the vmpck key exists, a guest running at VMPL2 
could request a VMPL0 report using the vmpck0 key, that is why it is 
important that the SVSM clear to zero any vmpck key that represents a 
higher privilege. For example, if the SVSM (running at VMPL0) launches 
the guest at VMPL2, it should zero out the vmpck0 and vmpck1 keys in the 
SNP Secrets Page supplied to the guest.

> 
> Do users know that "vmpl" and "vmpck_id" are interchangeable?

Yes, they should be aware of the relation of VMPL to VMPCK from the SNP 
specification.

Thanks,
Tom

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ