On 4/24/23 04:45, Gerd Hoffmann wrote:
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?
I'd have to dig much deeper to see if there's a way to identify whether a
VARS file was specified on the Qemu command line. I *think* (please
correct me if I'm missing something) for SEV and SEV-ES it would be
straight forward to try and access the memory as shared and check the
headers. If they're valid, then a VARS file was specified on the command
line and should remain mapped shared. If they aren't valid, a VARS file
wasn't specified and you have either the full OVMF.fd file or just the
OVMF_CODE.fd with memory backing the VARS that, in either case, should be
mapped private.
I think the problem may come in with SNP where if the mapping isn't
correct (shared mapping against a page that has been validated or a
private mapping against a page that hasn't been validated) you can end up
with #NPFs or #VCs and having to figure out what or why you are getting those.
Let me see what I can find... I'm off the next few days so it might be a bit.
Thanks,
Tom
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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#103665): https://edk2.groups.io/g/devel/message/103665
Mute This Topic: https://groups.io/mt/97922617/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
