public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu>
To: Fiona Ebner <f.ebner@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server v3 4/5] config: add AMD SEV-SNP support.
Date: Tue, 11 Mar 2025 14:56:36 +0100	[thread overview]
Message-ID: <ohu7nlfsnj7efw3sirwuckk5zeuuykhfs3jkui5r4txahavfwr@sgdqd3vzcntc> (raw)
In-Reply-To: <e51497ff-4ec0-4e4e-904e-c8cf75b96edc@proxmox.com>

On 25/03/05 04:35PM, Fiona Ebner wrote:
> Am 24.02.25 um 13:37 schrieb Philipp Giersfeld:
> > This patch is for enabling AMD SEV-SNP support.
> > 
> > Where applicable, it extends support for existing SEV(-ES) variables
> > to SEV-SNP. This means that it retains no-debug and kernel-hashes
> > options, but the no-key-sharing option is removed.
> > 
> > The default policy value is identical to QEMU’s, and the therefore
> > required option has been added to configure SMT support.
> > 
> > The code was tested by running a VM without SEV, with SEV, SEV-ES,
> > SEV-SNP. Each configuration was tested with and without an EFI disk
> > attached. For SEV-enabled configurations it was also verified that the
> > kernel actually used the respective feature.
> > 
> > Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu>
> > Reviewed-by: Daniel Kral <d.kral@proxmox.com>
> > Tested-by: Markus Frank <m.frank@proxmox.com>
> > ---
> > 
> >  no changes since last version
> > 
> >  PVE/API2/Qemu.pm            |  7 +++-
> >  PVE/QemuServer.pm           | 49 +++++++++++++++++++--------
> >  PVE/QemuServer/CPUConfig.pm | 66 ++++++++++++++++++++++++++++---------
> >  3 files changed, 92 insertions(+), 30 deletions(-)
> > 
> > diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> > index 295260e7..4f48cf85 100644
> > --- a/PVE/API2/Qemu.pm
> > +++ b/PVE/API2/Qemu.pm
> > @@ -548,8 +548,13 @@ my sub create_disks : prototype($$$$$$$$$$$) {
> >  		my $volid;
> >  		if ($ds eq 'efidisk0') {
> >  		    my $smm = PVE::QemuServer::Machine::machine_type_is_q35($conf);
> > +
> > +		    my $amd_sev_type = PVE::QemuServer::CPUConfig::get_amd_sev_type($conf);
> > +		    die "SEV-SNP uses consolidated read-only firmware"
> 
> Missing newline at the end of error message. Perl will automatically
> attach the filename and line number then, which is rather ugly here. I'd
> also mention "and doesn't need an EFI disk" to clarify this a bit more
> for users.

Does "SEV-SNP uses consolidated read-only firmware instead of a seperate
non-volatile variable store\n" work?

> 
> > +			if $amd_sev_type && $amd_sev_type eq 'snp';
> > +
> >  		    ($volid, $size) = PVE::QemuServer::create_efidisk(
> > -			$storecfg, $storeid, $vmid, $fmt, $arch, $disk, $smm);
> > +			$storecfg, $storeid, $vmid, $fmt, $arch, $disk, $smm, $amd_sev_type);
> >  		} elsif ($ds eq 'tpmstate0') {
> >  		    # swtpm can only use raw volumes, and uses a fixed size
> >  		    $size = PVE::Tools::convert_size(PVE::QemuServer::Drive::TPMSTATE_DISK_SIZE, 'b' => 'kb');
> > diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> > index 808c0e1c..51e551b8 100644
> > --- a/PVE/QemuServer.pm
> > +++ b/PVE/QemuServer.pm
> > @@ -52,7 +52,7 @@ use PVE::QemuConfig;
> >  use PVE::QemuServer::Helpers qw(config_aware_timeout min_version kvm_user_version windows_version);
> >  use PVE::QemuServer::Cloudinit;
> >  use PVE::QemuServer::CGroup;
> > -use PVE::QemuServer::CPUConfig qw(print_cpu_device get_cpu_options get_cpu_bitness is_native_arch get_amd_sev_object);
> > +use PVE::QemuServer::CPUConfig qw(print_cpu_device get_cpu_options get_cpu_bitness is_native_arch get_amd_sev_object get_amd_sev_type);
> >  use PVE::QemuServer::Drive qw(is_valid_drivename checked_volume_format drive_is_cloudinit drive_is_cdrom drive_is_read_only parse_drive print_drive);
> >  use PVE::QemuServer::Machine;
> >  use PVE::QemuServer::Memory qw(get_current_memory);
> > @@ -88,6 +88,13 @@ my $OVMF = {
> >  	    "$EDK2_FW_BASE/OVMF_CODE_4M.secboot.fd",
> >  	    "$EDK2_FW_BASE/OVMF_VARS_4M.ms.fd",
> >  	],
> > +	'4m-sev' => [
> > +	    "$EDK2_FW_BASE/OVMF_CVM_CODE_4M.fd",
> > +	    "$EDK2_FW_BASE/OVMF_CVM_VARS_4M.fd", 
> 
> Style nit: trailing whitespace above
> 
> Is switching over for the std+ES SEV scenarios still
> required/advantageous if we go for edk2-stable202502?

From my testing this is still the case.
IIUC, this is because the existing firmware is built targeting
OmvfPkg/OvmfPkgI32X64.dsc which does not support SEV.

> 
> > +	],
> > +	'4m-snp' => [
> > +	    "$EDK2_FW_BASE/OVMF_CVM_4M.fd",
> > +	],
> >  	# FIXME: These are legacy 2MB-sized images that modern OVMF doesn't supports to build
> >  	# anymore. how can we deperacate this sanely without breaking existing instances, or using
> >  	# older backups and snapshot?
> > @@ -3172,15 +3179,22 @@ sub vga_conf_has_spice {
> >      return $1 || 1;
> >  }
> >  
> > -sub get_ovmf_files($$$) {
> > -    my ($arch, $efidisk, $smm) = @_;
> > +sub get_ovmf_files($$$$) {
> > +    my ($arch, $efidisk, $smm, $amd_sev_type) = @_;
> >  
> >      my $types = $OVMF->{$arch}
> >  	or die "no OVMF images known for architecture '$arch'\n";
> >  
> >      my $type = 'default';
> >      if ($arch eq 'x86_64') {
> > -	if (defined($efidisk->{efitype}) && $efidisk->{efitype} eq '4m') {
> > +	if ($amd_sev_type && $amd_sev_type eq 'snp') {
> > +	    $type = "4m-snp";
> > +	    my ($ovmf) = $types->{$type}->@*;
> > +	    die "EFI base image '$ovmf' not found\n" if ! -f $ovmf;
> > +	    return ($ovmf);
> > +	} elsif ($amd_sev_type) {
> > +	    $type = "4m-sev";
> > +	} elsif (defined($efidisk->{efitype}) && $efidisk->{efitype} eq '4m') {
> >  	    $type = $smm ? "4m" : "4m-no-smm";
> >  	    $type .= '-ms' if $efidisk->{'pre-enrolled-keys'};
> >  	} else {
> > @@ -3329,7 +3343,8 @@ my sub print_ovmf_drive_commandlines {
> >  
> >      my $d = $conf->{efidisk0} ? parse_drive('efidisk0', $conf->{efidisk0}) : undef;
> >  
> > -    my ($ovmf_code, $ovmf_vars) = get_ovmf_files($arch, $d, $q35);
> > +    my $amd_sev_type = get_amd_sev_type($conf);
> 
> I'd die here if the type is 'snp' just to be sure, so that we have a
> clear error should that ever happen by accident.

Ack

> 
> > +    my ($ovmf_code, $ovmf_vars) = get_ovmf_files($arch, $d, $q35, $amd_sev_type);
> >  
> >      my $var_drive_str = "if=pflash,unit=1,id=drive-efidisk0";
> >      if ($d) {
> > @@ -3526,10 +3541,17 @@ sub config_to_command {
> >  	die "OVMF (UEFI) BIOS is not supported on 32-bit CPU types\n"
> >  	    if !$forcecpu && get_cpu_bitness($conf->{cpu}, $arch) == 32;
> >  
> > -	my ($code_drive_str, $var_drive_str) =
> > -	    print_ovmf_drive_commandlines($conf, $storecfg, $vmid, $arch, $q35, $version_guard);
> > -	push $cmd->@*, '-drive', $code_drive_str;
> > -	push $cmd->@*, '-drive', $var_drive_str;
> > +	my $amd_sev_type = get_amd_sev_type($conf);
> > +	if ($amd_sev_type && $amd_sev_type eq 'snp') {
> > +	   my $arch = PVE::QemuServer::Helpers::get_vm_arch($conf);
> > +	   my $d = $conf->{efidisk0} ? parse_drive('efidisk0', $conf->{efidisk0}) : undef;
> 
> Since the EFI disk is not used in this case, we should always pass undef
> to be explicit. We can print an informational message that it will be
> ignored if present.
> 
> > +	   push $cmd->@*, '-bios', get_ovmf_files($arch, $d, undef, $amd_sev_type);
> > +	} else {
> > +	    my ($code_drive_str, $var_drive_str) = print_ovmf_drive_commandlines(
> > +		$conf, $storecfg, $vmid, $arch, $q35, $version_guard);
> > +	    push $cmd->@*, '-drive', $code_drive_str;
> > +	    push $cmd->@*, '-drive', $var_drive_str;
> > +	}
> >      }
> >  
> >      if ($q35) { # tell QEMU to load q35 config early
> 
> ---snip 8<---
> 
> > @@ -231,25 +232,32 @@ my $cpu_fmt = {
> >  my $sev_fmt = {
> >      type => {
> >  	description => "Enable standard SEV with type='std' or enable"
> > -	    ." experimental SEV-ES with the 'es' option.",
> > +	    ." experimental SEV-ES with the 'es' option or enable "
> > +	    ."experimental SEV-SNP with the 'snp' option.",
> 
> Style nit: it's preferred to use the space at the beginning of the next
> line: https://pve.proxmox.com/wiki/Perl_Style_Guide#Wrapping_Strings
> 
Ack.
> >  	type => 'string',
> >  	default_key => 1,
> >  	format_description => "sev-type",
> > -	enum => ['std', 'es'],
> > +	enum => ['std', 'es', 'snp'],
> >  	maxLength => 3,
> >      },
> >      'no-debug' => {
> > -	description => "Sets policy bit 0 to 1 to disallow debugging of guest",
> > +	description => "Sets policy bit to disallow debugging of guest",
> >  	type => 'boolean',
> >  	default => 0,
> >  	optional => 1,
> >      },
> >      'no-key-sharing' => {
> > -	description => "Sets policy bit 1 to 1 to disallow key sharing with other guests",
> > +	description => "Sets policy bit to disallow key sharing with other guests",
> 
> I'd also mention that it is ignored if using SNP
> 
Ack
> >  	type => 'boolean',
> >  	default => 0,
> >  	optional => 1,
> >      },
> > +    'allow-smt' => {
> > +	description => "Sets policy bit to allow Simultaneous Multi Threading (SMT)",
> 
> I'd also mention that it is ignored if not using SNP
> 
Ack
> > +	type => 'boolean',
> > +	default => 1,
> > +	optional => 1,
> > +    },
> >      "kernel-hashes" => {
> >  	description => "Add kernel hashes to guest firmware for measured linux kernel launch",
> >  	type => 'boolean',
> > @@ -823,6 +831,13 @@ sub get_hw_capabilities {
> >      }
> >      return $hw_capabilities;
> >  }
> > +sub get_amd_sev_type {
> > +    my ($conf) = @_;
> > +
> > +    return undef if !$conf->{'amd-sev'};
> > +
> > +    return PVE::JSONSchema::parse_property_string($sev_fmt, $conf->{'amd-sev'})->{type};
> > +}
> >  
> >  sub get_amd_sev_object {
> >      my ($amd_sev, $bios) = @_;
> > @@ -836,22 +851,41 @@ sub get_amd_sev_object {
> >      if ($amd_sev_conf->{type} eq 'es' && !$sev_hw_caps->{'sev-support-es'}) {
> >  	die "Your CPU does not support AMD SEV-ES.\n";
> >      }
> > +    if ($amd_sev_conf->{type} eq 'snp' && !$sev_hw_caps->{'sev-support-snp'}) {
> > +	die "Your CPU does not support AMD SEV-SNP.\n";
> > +    }
> >      if (!$bios || $bios ne 'ovmf') {
> >  	die "To use AMD SEV, you need to change the BIOS to OVMF.\n";
> >      }
> >  
> > -    my $sev_mem_object = 'sev-guest,id=sev0';
> > -    $sev_mem_object .= ',cbitpos='.$sev_hw_caps->{cbitpos};
> > -    $sev_mem_object .= ',reduced-phys-bits='.$sev_hw_caps->{'reduced-phys-bits'};
> > -
> > -    # guest policy bit calculation as described here:
> > -    # https://documentation.suse.com/sles/15-SP5/html/SLES-amd-sev/article-amd-sev.html#table-guestpolicy
> > -    my $policy = 0;
> > -    $policy |= 1 << 0 if $amd_sev_conf->{'no-debug'};
> > -    $policy |= 1 << 1 if $amd_sev_conf->{'no-key-sharing'};
> > -    $policy |= 1 << 2 if $amd_sev_conf->{type} eq 'es';
> > -    # disable migration with bit 3 nosend to prevent amd-sev-migration-attack
> > -    $policy |= 1 << 3;
> > +    my $sev_mem_object = '';
> > +    my $policy;
> > +    if ($amd_sev_conf->{type} eq 'es' || $amd_sev_conf->{type} eq 'std') {
> > +	$sev_mem_object .= 'sev-guest,id=sev0';
> > +	$sev_mem_object .= ',cbitpos='.$sev_hw_caps->{cbitpos};
> > +	$sev_mem_object .= ',reduced-phys-bits='.$sev_hw_caps->{'reduced-phys-bits'};
> > +
> > +	# guest policy bit calculation as described here:
> > +	# https://documentation.suse.com/sles/15-SP5/html/SLES-amd-sev/article-amd-sev.html#table-guestpolicy
> > +	$policy = 0;
> > +	$policy |= 1 << 0 if $amd_sev_conf->{'no-debug'};
> > +	$policy |= 1 << 1 if $amd_sev_conf->{'no-key-sharing'};
> > +	$policy |= 1 << 2 if $amd_sev_conf->{type} eq 'es';
> > +	# disable migration with bit 3 nosend to prevent amd-sev-migration-attack
> > +	$policy |= 1 << 3;
> > +    } elsif ($amd_sev_conf->{type} eq 'snp') {
> > +	$sev_mem_object .= 'sev-snp-guest,id=sev0';
> > +	$sev_mem_object .= ',cbitpos='.$sev_hw_caps->{cbitpos};
> > +	$sev_mem_object .= ',reduced-phys-bits='.$sev_hw_caps->{'reduced-phys-bits'};
> > +
> > +	# guest policy bit calculation as described in chapter 4.3:
> > +	# https://www.amd.com/system/files/TechDocs/56860.pdf
> > +	# Reserved bit must be one
> > +	$policy = 1 << 17;
> > +	$policy |= 1 << 16 if $amd_sev_conf->{'allow-smt'};
> 
> In the schema, the default is set to 1. Note that this is only
> informational unfortunately, i.e. parse_property_string() will not fill
> in a default. You need to apply the default yourself here using
> 
> > if !defined($amd_sev_conf->{'allow-smt'}) || $amd_sev_conf->{'allow-smt'};
> 
Ack
> 
> > +	$policy |= 1 << 19 if !$amd_sev_conf->{'no-debug'};
> 
> Note that here, it already works automatically, because the default is 0.
> 
> > +    }
> > +
> >  
> >      $sev_mem_object .= ',policy='.sprintf("%#x", $policy);
> >      $sev_mem_object .= ',kernel-hashes=on' if ($amd_sev_conf->{'kernel-hashes'});
> 
> 

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  reply	other threads:[~2025-03-11 13:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-24 12:37 [pve-devel] [PATCH edk2-firmware/qemu-server/manager v3 0/5] AMD SEV-SNP Philipp Giersfeld
2025-02-24 12:37 ` [pve-devel] [PATCH edk2-firmware v3 1/5] Update edk2 to edkstable202411 Philipp Giersfeld
2025-03-05 16:51   ` [pve-devel] applied: " Thomas Lamprecht
2025-02-24 12:37 ` [pve-devel] [PATCH edk2-firmware v3 2/5] Add OVMF targets for AMD SEV-ES and SEV-SNP Philipp Giersfeld
2025-03-05 14:18   ` Fiona Ebner
2025-03-05 15:35     ` Thomas Lamprecht
2025-03-11 12:31     ` Philipp Giersfeld
2025-02-24 12:37 ` [pve-devel] [PATCH qemu-server v3 3/5] Convert policy calculation Philipp Giersfeld
2025-03-05 15:35   ` Fiona Ebner
2025-02-24 12:37 ` [pve-devel] [PATCH qemu-server v3 4/5] config: add AMD SEV-SNP support Philipp Giersfeld
2025-03-05 15:35   ` Fiona Ebner
2025-03-11 13:56     ` Philipp Giersfeld [this message]
2025-03-11 14:22       ` Fiona Ebner
2025-02-24 12:37 ` [pve-devel] [PATCH pve-manager v3 5/5] Add configuration options for AMD SEV-SNP Philipp Giersfeld
2025-03-05  8:31 ` [pve-devel] [PATCH edk2-firmware/qemu-server/manager v3 0/5] " Philipp Giersfeld

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=ohu7nlfsnj7efw3sirwuckk5zeuuykhfs3jkui5r4txahavfwr@sgdqd3vzcntc \
    --to=philipp.giersfeld@canarybit.eu \
    --cc=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal