linux-kernel - Re: 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: <20130801165150.GB7445@pd.tnic>
Date:	Thu, 1 Aug 2013 18:51:50 +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 10:54:23PM +0100, Matthew Garrett wrote:
> 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.

Actually, with UEFI impl. f*ckup like that, I'd rather kick it back to
the curb and simply not init runtime services instead of fixing stuff
around it. SetVirtualAddressMap in itself is a f*ckup as it is already.

Oh well, let's see what edk2 guys would say first.

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