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]

Message-ID: <51FF8C14.2070405@redhat.com>
Date:	Mon, 05 Aug 2013 13:27:16 +0200
From:	Laszlo Ersek <lersek@...hat.com>
To:	Borislav Petkov <bp@...en8.de>
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>
Subject: Re: [edk2] Corrupted EFI region

On 08/01/13 18:49, Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 10:55:27PM +0100, David Woodhouse wrote:
>> 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-devel@...ts.sourceforge.net list should be in Cc?
> 
> Good idea and message repeated below.
> 
> One more thing: I'm using a self-built OVMF with top commit from March:
> 
> ------------------------------------------------------------------------
> r14165 | sfu5 | 2013-03-06 02:42:04 +0100 (Wed, 06 Mar 2013) | 4 lines
> 
> Fix a bug that IsSignatureFoundInDatabase() incorrectly computes CertCount.
> 
> ---
> 
> 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=[0x0000000040000000-0x000000007c000000) (960MB)
>  efi: mem09: type=4, attr=0xf, range=[0x000000007c000000-0x000000007c020000) (0MB)
>  efi: mem10: type=7, attr=0xf, range=[0x000000007c020000-0x000000007e0ad000) (32MB)
> -efi: mem11: type=4, attr=0xf, range=[0x000000007e0ad000-0x000000007e0cc000) (0MB)
> +efi: mem11: type=4, attr=0xf, range=[0x000000007e0ad000-0x000000007e0ad000) (0MB)

(type 4 is EfiBootServicesData)

>  efi: mem12: type=7, attr=0xf, range=[0x000000007e0cc000-0x000000007e0cd000) (0MB)
>  efi: mem13: type=4, attr=0xf, range=[0x000000007e0cd000-0x000000007e55d000) (4MB)
>  efi: mem14: type=3, attr=0xf, range=[0x000000007e55d000-0x000000007e59c000) (0MB)
> 
> That second boundary of region mem11 suddenly changes *before* we merge
> the regions. edk2 bug?

I take it you mean this change (ie. appearance of the zero-sized range)
occurs when you enable KVM acceleration in qemu?

If so, please locate "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel"
in OvmfPkg/OvmfPkgX64.dsc, and set the following bit in its value:

  # DEBUG_GCD      0x00100000 Global Coherency Database changes

Then please rebuild OVMF, and capture the debug port output of qemu
("-debugcon file:debug.log -global isa-debugcon.iobase=0x402") both with
and without KVM.

DEBUG_GCD should produce messages related to CoreAllocateSpace(), and
might help us find the spot the difference is introduced.

BTW does this have anything to do with the NX bit report of yours, or
have you noticed this independently?

(I'm not subscribed to lkml so apologies if this email doesn't end up in
those archives / doesn't reach everyone.)

Thanks
Laszlo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/