linux-kernel - Re: [edk2] Corrupted EFI region

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 Aug 2013 17:19:35 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Laszlo Ersek <lersek@...hat.com>
Cc:	edk2-devel@...ts.sourceforge.net,
	David Woodhouse <dwmw2@...radead.org>,
	linux-efi@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
	Gleb Natapov <gleb@...hat.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Matt Fleming <matt@...sole-pimps.org>
Subject: Re: [edk2] Corrupted EFI region

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:

  gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8010007F

(I just set all three bits you requested).

Using the new OVMF.id 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)

from

[    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
not.

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 :).

Thanks.

-- 
Regards/Gruss,
    Boris.

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

Download attachment "ovmf-dbg.tar.bz2" of type "application/octet-stream" (143606 bytes)