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:	Mon, 05 Aug 2013 08:34:49 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Laszlo Ersek <lersek@...hat.com>
Cc:	Borislav Petkov <bp@...en8.de>, 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, 2013-08-05 at 17:15 +0200, Laszlo Ersek wrote:
> On 08/05/13 16:40, Borislav Petkov wrote:
> > On Mon, Aug 05, 2013 at 04:27:44PM +0200, Laszlo Ersek wrote:
> >> I wouldn't call the design of SetVirtualAddressMap() braindead.
> > 
> > Ok, I've always wondered and you could probably shed some light on the
> > matter: why is SetVirtualAddressMap() a call-once only? Why can't I
> > simply call it again and update the mappings?
> 
> The current implementation (how pointers are converted) probably doesn't
> accommodate a second call.

Having actually looked at the code (trying to find why we were getting
an unconverted pointer), I second that.  However, the ugliness of the
massive pointer chase should have been an indication that something was
not quite right architecturally (or implementation wise) with
SetVirtualAddressMap().

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

That thinking is a bit last century (not that I'm blaming you for it, it
seems to be ingrained in the way UEFI sometimes goes about things) ...
in the old days, DOS was bootstrapped by the 512 byte jump code in a
well known sector.  In the current century, almost every OS is
bootstrapped by a sophisticated loader, which is effectively another OS
(if you don't believe this, try looking at the grub source code one
day); it's a short step from this to one OS booting another, and that's
really what kexec is.  The utility of kexec has proven itself over the
past couple of decades or so by allowing us to dump (kexec to a dump
kernel), short circuit the boot process (simply re-kexec the kernel on
crash) and now do rebootless upgrades (checkpoint the userspace and
kexec to the new kernel).  It's not even unique to Linux: Solaris used a
hidden kexec system call to do live upgrades as well and I believe
several other UNIXs have this feature.

James

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