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: <20130805161247.GF31845@pd.tnic>
Date:	Mon, 5 Aug 2013 18:12:47 +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>
Subject: Re: [edk2] Corrupted EFI region

On Mon, Aug 05, 2013 at 05:15:38PM +0200, Laszlo Ersek wrote:
> The current implementation (how pointers are converted) probably doesn't
> accommodate a second call.
> 
> Of course you want to know why SetVirtualAddressMap() was designed like
> that... I didn't participate in the design so I don't know :)
> 
> But, as I said, a kernel directly executing another kernel is an
> unexpected idea. IMHO the second kernel in question doesn't fit the UEFI
> phases at all. The OS booted like that (ie. the OS whose kernel is the
> 2nd (=kexec) kernel) never goes through SEC, PEI, DXE, BDS.

Yes, the thing is, imposing unnecessary restrictions is very
counterproductive. And kexec is just an example here - if
SetVirtualAddressMap was callable an arbitrary number of times, this
whole work I'm doing is unnecessary. So I'm jumping through hoops just
to accomodate a braindead design.

This is what I cannot fathom in the face of people praising UEFI as the
solution to all problems. Where in fact it causes more, and needlessly
at that.

> That doesn't matter as long as the UEFI designers aren't aware of it :)

Well, it wouldn't have hurt if they at least looked around what's out
there...

> (Who should have made whom aware, ie. Linux people approaching UEFI
> people, or UEFI people exploring Linux, is a separate topic. As always
> I'm apolitical about UEFI; I'm not arguing for it or against it. My
> feeble efforts for improving OVMF and interfacing code are motivated by
> my employer, not my world view, but as a side-effect of working with the
> code I can't help but notice some nice things in edk2 and appreciate
> them :))

No, I completely understand. I was simply asking whether you've managed
to see an aspect which made sense for SetVirtualAddressMap to be
callable only once and to enlighten me about it because I can't see one
so far.

> Insult my code or my analysis pls.

I won't and I don't need to insult anybody or anything. :)

> BTW there's another point I'd like to ask about -- you're saying you
> see the region corruption during the same boot, from the first (early)
> memmap dump to the second one (when just about to enter virtual mode).
> But, is this one boot the very first boot, or the kexec one?

No, kexec is not even involved yet. If you look at the timestamps,
there's 0.005 seconds between the two dumps during the *same* kernel
booting on the machine, baremetal, straight from grub.

Thanks.

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