On Mon, 2013-03-18 at 14:23 +0000, James Bottomley wrote: > On Mon, 2013-03-18 at 11:49 +0000, Matt Fleming wrote: > > On Mon, 2013-03-18 at 08:01 +0000, James Bottomley wrote: > > > The crash is attached below. The curiosity is that the failing > > > "virtual" address is actually a physical address inside the EFI runtime. > > > It looks like either SetVirtualAddressMap() failed to relocate > > > something, or there are caching effects on pre-relocated addresses. > > > > > > The way to trigger this is to run tianocore in kvm and boot to an > > > initial ramdisk with the efi tools and a shell. If I insert a PK in the > > > UEFI shell and then try to remove it in the initrd, the crash happens. > > > If, however, I try to insert and remove the PK in the initrd without > > > touching the secure variables in the UEFI shell, everything works > > > > > > James > > > > Crashes like this are typical of firmware that fails to update its > > internal pointers when SetVirtualAddressMap() is called. There's no > > reason that any of the EFI runtime services regions should be skipped > > when establishing virtual kernel mappings, unless those regions are > > missing the EFI_MEMORY_RUNTIME attribute, which seems unlikely. > > Yes, it's a phenomenally complicated operation from looking at the > TianoCore source ... might we not be better off not bothering to > relocate and just using a private physical mapping for the calls? There's a lot to be said for that. It would fix kexec too — which is currently broken because you're only allowed to call SetVirtualAddressMap once. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
