On 10/01/17 11:17, Laszlo Ersek wrote: > (3) Implement SEV encryption for pflash. A pflash chip can be in one of > two modes: (a) it reads and executes as ROM, or (b) it behaves like a > programmable (r/w) device with MMIO registers. Switching between both > modes is explicit (see > "OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c"); perhaps some SEV > controls could be hooked in there. Hmmm wait a second, we *already* execute code from pflash (namely SEC code from OVMF_CODE.fd), and instruction fetch always entails decryption. Furthermore, in SEC, we decompress PEI and DXE FVs from pflash (OVMF_CODE.fd) to RAM -- the decompression code runs in long mode, plus you modified the OVMF/X64 reset vector to set the C-bit in all PTEs, covering the low 4GB of guest RAM. This tells me that at least read and execute from pflash work with SEV decryption already. Is this expected? However, in PlatformPei, we don't report the varstore pflash range via any resource descriptor HOB (the varstore chip is at [0xffc00000, 0xFFC84000) in the 4MB build). Consequently, AmdSevDxe clears the C-bit under the "NonExistent" branch: AmdSevDxe:SetMemoryEncDec: Cr3Base=0x0 Physical=0xFEF00000 Length=0x1100000 Mode=Decrypt CacheFlush=0 Subsequently, "OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c" adds the pflash range as EFI_MEMORY_UC | EFI_MEMORY_RUNTIME. The C-bit remains clear, AIUI. OK, I'm totally confused now. Looks like SEV decryption already works for pflash (from SEC's example), and transparently at that (???), but we fail to use it in QemuFlashFvbServicesRuntimeDxe? Laszlo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
