public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: "Xu, Min M" <min.m.xu@intel.com>, joeyli <jlee@suse.com>,
	 "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	 James Bottomley <jejb@linux.ibm.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	 Michael Roth <michael.roth@amd.com>
Subject: Re: [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest
Date: Mon, 24 Apr 2023 11:45:42 +0200	[thread overview]
Message-ID: <ydccabh7bb74bzw4cop7vo5eqckubzhcvo4baszizjjzrkrhbl@e24qj2v2cspv> (raw)
In-Reply-To: <0da93279-d397-c067-cc9f-7abfc9935eea@amd.com>

On Fri, Apr 21, 2023 at 03:49:27PM -0500, Tom Lendacky wrote:
> On 4/21/23 04:18, Gerd Hoffmann wrote:
> > > > Hmm, good question.  Can the guest figure what memory ranges are part
> > > > of the launch measurement?
> > > > 
> > > > I have a patch here (attached below) which refines flash detection and
> > > > can detect whenever varstore flash is writable or not.  I suspect that
> > > > doesn't help much though as flash probing requires mappings already
> > > > being correct.
> > > 
> > > Sorry for the delay, but, yeah, doesn't help. SEV and SEV-ES assert and
> > > SEV-SNP terminates because of accessing a shared page (in the RMP) as a
> > > private page (we don't support the generated 0x404 error code in the #VC
> > > handler).
> > 
> > Can you try this?
> > https://github.com/kraxel/edk2/commits/devel/secure-boot-pcd
> 
> It works for the split vars/code launch, but fails for the combined
> vars/code launch:
> 
> EMU Variable FVB Started
> EMU Variable FVB: Using pre-reserved block at 7FE7C000
> EMU Variable FVB: Basic FV headers were invalid
> EMU Variable FVB: SecureBoot: restore FV from ROM
> EMU Variable FVB: Basic FV headers were invalid
> ASSERT [EmuVariableFvbRuntimeDxe] /root/kernels/ovmf-gerd-build-X64/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c(781): ((BOOLEAN)(0==1))
> 
> So the mapping isn't correct at this point either.

Log looks like this for me, using grep -Ei '(fvb|flash|amdsev)'

Loading driver at 0x0003F022000 EntryPoint=0x0003F0245B5 AmdSevDxe.efi
Loading driver at 0x0003F6E4000 EntryPoint=0x0003F6E7035 FvbServicesRuntimeDxe.efi
QEMU Flash: Attempting flash detection at FFC00010
QemuFlashDetected => FD behaves as ROM
QemuFlashDetected => No
QEMU flash was not detected. Writable FVB is not being installed.
Loading driver at 0x0003F6D3000 EntryPoint=0x0003F6D55B9 EmuVariableFvbRuntimeDxe.efi
EMU Variable FVB Started
EMU Variable FVB: Using pre-reserved block at 3FEF4000
EMU Variable FVB: Basic FV headers were invalid
Installing FVB for EMU Variable support

So AmdSevDxe is loaded first, next comes FvbServicesRuntimeDxe, finally
EmuVariableFvbRuntimeDxe.

So AmdSev should have (in theory, in practice obviously not ...) setup
everything at that point I assume?

Failing that FvbServicesRuntimeDxe might do it as well, there actually
is some code doing so to fixup things after calling
SetMemorySpaceAttributes (see MarkIoMemoryRangeForRuntimeAccess).

Maybe that should also be called before QemuFlashInitialize() so the SEV
settings are correct when OVMF goes do flash detection?

take care,
  Gerd


  reply	other threads:[~2023-04-24  9:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29  5:23 [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest Min Xu
2023-03-30  7:50 ` Gerd Hoffmann
2023-03-31  7:59   ` joeyli
2023-03-31  8:25     ` Gerd Hoffmann
2023-03-31 14:48       ` joeyli
2023-04-03  0:21         ` Min Xu
2023-04-03 11:20           ` Gerd Hoffmann
2023-04-06  1:42             ` Min Xu
2023-04-06 20:28               ` Lendacky, Thomas
2023-04-07  1:56                 ` Min Xu
2023-04-07 14:49                   ` [edk2-devel] " joeyli
2023-04-07 17:00                   ` Lendacky, Thomas
2023-04-11 10:04                     ` Gerd Hoffmann
2023-04-11 18:03                       ` Lendacky, Thomas
2023-04-12  7:24                         ` Gerd Hoffmann
2023-04-12 15:23                           ` Lendacky, Thomas
2023-04-13  6:05                             ` Gerd Hoffmann
2023-04-13 13:58                               ` Lendacky, Thomas
2023-04-14 10:20                                 ` Gerd Hoffmann
2023-04-20 15:16                                   ` Lendacky, Thomas
2023-04-21  9:18                                     ` Gerd Hoffmann
2023-04-21 20:49                                       ` Lendacky, Thomas
2023-04-24  9:45                                         ` Gerd Hoffmann [this message]
2023-04-26 20:43                                           ` Lendacky, Thomas
2023-04-28  8:41                                             ` Gerd Hoffmann
2023-05-01 19:06                                               ` Lendacky, Thomas
2023-04-07  9:41           ` joeyli
2023-04-07 11:54             ` Min Xu

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-list 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=ydccabh7bb74bzw4cop7vo5eqckubzhcvo4baszizjjzrkrhbl@e24qj2v2cspv \
    --to=devel@edk2.groups.io \
    /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