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: <20130731215130.GA6087@pd.tnic>
Date:	Wed, 31 Jul 2013 23:51:30 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Matt Fleming <matt@...sole-pimps.org>, linux-efi@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: Corrupted EFI region

On Wed, Jul 31, 2013 at 09:58:58PM +0100, Matthew Garrett wrote:
> On Wed, Jul 31, 2013 at 10:54:31PM +0200, Borislav Petkov wrote:
> 
> >  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)
> >  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)
> 
> Are we making any EFI calls in between?

Probably.

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

Well, we call ExitBootServices pretty early in exit_boot().

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.

I hope this is an edk2 only bug. Btw, I'm not running the latest version
so the hope that it could've been fixed in the meantime is not dead yet.

:)

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ