Re: [edk2] Corrupted EFI region

From: Borislav Petkov
Date: Wed Aug 07 2013 - 11:19:47 EST

On Tue, Aug 06, 2013 at 05:31:29PM +0200, Laszlo Ersek wrote:
> Can you capture the OVMF debug output? Do you see
> ConvertPages: Incompatible memory types
> there?
> Can you set the following bits too in the debug mask?
> #define DEBUG_POOL 0x00000010 // Alloc & Free's
> #define DEBUG_PAGE 0x00000020 // Alloc & Free's

Ok, I got debug output; I have to be careful now of not missing
anything. Ok, so here we go:

First of all, I changed debugging mask to:


(I just set all three bits you requested).

Using the new changed the addresses, of course, so we're looking
at 0x7dc59XXX ones now.

[ 0.000000] memblock_reserve: [0x0000007dc59018-0x0000007dc59618] efi_memblock_x86_reserve_range+0x70/0x75

So, I've attached an archive of the debug logs. The initial observations
I could do is that the region still gets "squashed" to:

[ 0.014041] efi: mem11: type=4, attr=0xf, range=[0x000000007dc59000-0x000000007dc59000) (0MB)


[ 0.000000] efi: mem11: type=4, attr=0xf, range=[0x000000007dc59000-0x000000007e146000) (4MB)

And the interesting stuff in the OVMF output is right at the end:

ConvertRange: 7DC59000-7DC5AFFF to 4
AddRange: 7DC59000-7DC5AFFF to 4
AllocatePoolI: Type 4, Addr 7DC59018 (len 16F0) 26,735,072
Jumping to kernel

We get that same output no matter if I boot it with "-enable-kvm" or

If the order of the debug messages is the same as the calls actually
happen, we AllocatePoolI to address 7DC59018 which we already have added
as a range. But I'm not going to pretend I even know the code so I'll
let you comment instead :).



Sent from a fat crate under my desk. Formatting is fine.

Attachment: ovmf-dbg.tar.bz2
Description: Binary data