Corrupted EFI region
Hi guys, so I'm seeing this funny thing where an EFI region changes when we enter efi_enter_virtual_mode when booting with edk2 on kvm. Here's the diff: --- before 2013-07-31 22:20:52.316039492 +0200 +++ after 2013-07-31 22:21:30.960731706 +0200 @@ -9,7 +9,7 @@ efi: mem07: type=2, attr=0xf, range=[0x0 efi: mem08: type=7, attr=0xf, range=[0x4000-0x7c00) (960MB) efi: mem09: type=4, attr=0xf, range=[0x7c00-0x7c02) (0MB) efi: mem10: type=7, attr=0xf, range=[0x7c02-0x7e0ad000) (32MB) -efi: mem11: type=4, attr=0xf, range=[0x7e0ad000-0x7e0cc000) (0MB) +efi: mem11: type=4, attr=0xf, range=[0x7e0ad000-0x7e0ad000) (0MB) efi: mem12: type=7, attr=0xf, range=[0x7e0cc000-0x7e0cd000) (0MB) efi: mem13: type=4, attr=0xf, range=[0x7e0cd000-0x7e55d000) (4MB) efi: mem14: type=3, attr=0xf, range=[0x7e55d000-0x7e59c000) (0MB) That second boundary of region mem11 suddenly changes *before* we merge the regions. edk2 bug? Whole dmesg attached. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- test-x86_64.log.gz Description: Binary data
Re: Corrupted EFI region
On Wed, Jul 31, 2013 at 10:54:31PM +0200, Borislav Petkov wrote: efi: mem08: type=7, attr=0xf, range=[0x4000-0x7c00) (960MB) efi: mem09: type=4, attr=0xf, range=[0x7c00-0x7c02) (0MB) efi: mem10: type=7, attr=0xf, range=[0x7c02-0x7e0ad000) (32MB) -efi: mem11: type=4, attr=0xf, range=[0x7e0ad000-0x7e0cc000) (0MB) +efi: mem11: type=4, attr=0xf, range=[0x7e0ad000-0x7e0ad000) (0MB) efi: mem12: type=7, attr=0xf, range=[0x7e0cc000-0x7e0cd000) (0MB) efi: mem13: type=4, attr=0xf, range=[0x7e0cd000-0x7e55d000) (4MB) efi: mem14: type=3, attr=0xf, range=[0x7e55d000-0x7e59c000) (0MB) Are we making any EFI calls in between? I certainly wouldn't expect the memory map to change after ExitBootServices, but up until that point the firmware's free to mess with it. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Corrupted EFI region
On Wed, Jul 31, 2013 at 11:51:30PM +0200, Borislav Petkov wrote: But the problem is, something messes up the upper boundary of the region and it is an EFI_BOOT_SERVICES_DATA region which we need for the runtime services mapping and if we can't map it properly, we're probably going to miss functionality or not have runtime at all. Easiest way around this would probably be to stash the address map after ExitBootServices() and compare it at SetVirtualAddressMap() time, then take the widest boundaries and trim the e820 map to match. This is obviously dependent upon the system not allocating anything further after that, but it seems safest. The worst case is finding the firmware writing over bits of the kernel. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Corrupted EFI region
On Wed, 2013-07-31 at 22:54 +0200, Borislav Petkov wrote: so I'm seeing this funny thing where an EFI region changes when we enter efi_enter_virtual_mode when booting with edk2 on kvm. Here's the diff: Perhaps the edk2-de...@lists.sourceforge.net list should be in Cc? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
