From: James Bottomley <James.Bottomley@HansenPartnership.com> To: Laszlo Ersek <lersek@redhat.com> Cc: Borislav Petkov <bp@alien8.de>, edk2-devel@lists.sourceforge.net, David Woodhouse <dwmw2@infradead.org>, linux-efi@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>, Matthew Garrett <mjg59@srcf.ucam.org> Subject: Re: [edk2] Corrupted EFI region Date: Mon, 05 Aug 2013 08:34:49 -0700 [thread overview] Message-ID: <1375716889.2163.12.camel@dabdike.int.hansenpartnership.com> (raw) In-Reply-To: <51FFC19A.1020204@redhat.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> To: Laszlo Ersek <lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>, edk2-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Gleb Natapov <gleb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> Subject: Re: [edk2] Corrupted EFI region Date: Mon, 05 Aug 2013 08:34:49 -0700 [thread overview] Message-ID: <1375716889.2163.12.camel@dabdike.int.hansenpartnership.com> (raw) In-Reply-To: <51FFC19A.1020204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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
next prev parent reply other threads:[~2013-08-05 15:34 UTC|newest] Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-31 20:54 Corrupted EFI region Borislav Petkov 2013-07-31 20:54 ` Borislav Petkov 2013-07-31 20:58 ` Matthew Garrett 2013-07-31 20:58 ` Matthew Garrett 2013-07-31 21:51 ` Borislav Petkov 2013-07-31 21:51 ` Borislav Petkov 2013-07-31 21:54 ` Matthew Garrett 2013-07-31 21:54 ` Matthew Garrett 2013-08-01 16:51 ` Borislav Petkov 2013-08-01 16:51 ` Borislav Petkov 2013-07-31 21:55 ` David Woodhouse 2013-07-31 21:55 ` David Woodhouse 2013-08-01 16:49 ` Borislav Petkov 2013-08-01 16:49 ` Borislav Petkov 2013-08-05 11:27 ` [edk2] " Laszlo Ersek 2013-08-05 11:27 ` Laszlo Ersek 2013-08-05 13:02 ` Borislav Petkov 2013-08-05 13:02 ` Borislav Petkov 2013-08-05 13:39 ` Laszlo Ersek 2013-08-05 13:39 ` Laszlo Ersek 2013-08-05 14:03 ` Borislav Petkov 2013-08-05 14:03 ` Borislav Petkov 2013-08-05 14:27 ` Laszlo Ersek 2013-08-05 14:27 ` Laszlo Ersek 2013-08-05 14:40 ` Borislav Petkov 2013-08-05 14:40 ` Borislav Petkov 2013-08-05 15:15 ` Laszlo Ersek 2013-08-05 15:15 ` Laszlo Ersek 2013-08-05 15:34 ` James Bottomley [this message] 2013-08-05 15:34 ` James Bottomley 2013-08-05 16:27 ` Laszlo Ersek 2013-08-05 16:27 ` Laszlo Ersek 2013-08-05 16:12 ` Borislav Petkov 2013-08-05 16:12 ` Borislav Petkov 2013-08-05 16:41 ` Laszlo Ersek 2013-08-05 16:41 ` Laszlo Ersek 2013-08-05 16:47 ` Borislav Petkov 2013-08-05 16:47 ` Borislav Petkov 2013-08-05 17:00 ` Kinney, Michael D 2013-08-05 17:00 ` Kinney, Michael D 2013-08-05 17:09 ` Laszlo Ersek 2013-08-05 17:09 ` Laszlo Ersek 2013-08-05 21:26 ` Laszlo Ersek 2013-08-05 21:26 ` Laszlo Ersek 2013-08-05 22:08 ` Borislav Petkov 2013-08-05 22:08 ` Borislav Petkov 2013-08-06 14:10 ` Borislav Petkov 2013-08-06 14:10 ` Borislav Petkov 2013-08-06 15:31 ` Laszlo Ersek 2013-08-06 15:31 ` Laszlo Ersek 2013-08-07 15:19 ` Borislav Petkov 2013-08-07 17:23 ` Andrew Fish 2013-08-07 17:23 ` Andrew Fish 2013-08-07 20:19 ` Matt Fleming 2013-08-07 20:19 ` Matt Fleming 2013-08-07 20:24 ` Matt Fleming 2013-08-07 20:24 ` Matt Fleming 2013-08-07 21:10 ` Andrew Fish 2013-08-07 21:10 ` Andrew Fish 2013-08-07 21:23 ` Matthew Garrett 2013-08-08 10:17 ` Matt Fleming 2013-08-08 10:17 ` Matt Fleming 2013-08-08 13:46 ` Andrew Fish 2013-08-08 13:46 ` Andrew Fish 2013-09-02 8:19 ` Matt Fleming 2013-09-02 8:19 ` Matt Fleming 2013-09-13 20:38 ` jerry.hoemann 2013-09-13 20:38 ` jerry.hoemann-VXdhtT5mjnY 2013-09-16 10:59 ` Matt Fleming 2013-09-16 10:59 ` Matt Fleming 2013-09-16 11:50 ` Laszlo Ersek 2013-09-16 11:50 ` Laszlo Ersek 2013-09-16 15:57 ` Josh Triplett 2013-09-16 15:57 ` Josh Triplett 2013-09-16 16:25 ` Laszlo Ersek 2013-09-16 16:25 ` Laszlo Ersek 2013-09-16 16:27 ` Matthew Garrett 2013-09-16 16:27 ` Matthew Garrett 2013-09-16 16:29 ` Josh Triplett 2013-09-16 16:29 ` Josh Triplett 2013-09-18 19:24 ` jerry.hoemann 2013-09-18 19:24 ` jerry.hoemann-VXdhtT5mjnY 2013-09-20 9:06 ` Matt Fleming 2013-09-20 9:06 ` Matt Fleming 2013-08-07 17:49 ` Laszlo Ersek 2013-08-07 17:49 ` Laszlo Ersek 2013-08-08 15:02 ` Borislav Petkov 2013-08-08 15:02 ` Borislav Petkov 2013-08-08 21:45 ` Brian J. Johnson 2013-08-08 21:45 ` Brian J. Johnson 2013-08-18 7:33 ` Jordan Justen 2013-08-18 7:33 ` Jordan Justen 2013-08-05 15:50 ` Andrew Fish 2013-08-05 15:50 ` Andrew Fish 2013-08-05 18:12 ` Borislav Petkov 2013-08-05 18:12 ` Borislav Petkov 2013-08-05 21:37 ` H. Peter Anvin 2013-08-05 21:37 ` H. Peter Anvin 2013-08-05 21:41 ` Borislav Petkov 2013-08-05 21:41 ` Borislav Petkov 2013-08-05 21:49 ` H. Peter Anvin 2013-08-05 21:49 ` H. Peter Anvin 2013-08-05 21:55 ` Laszlo Ersek 2013-08-05 21:55 ` Laszlo Ersek 2013-08-05 22:52 ` James Bottomley 2013-08-05 22:52 ` James Bottomley 2013-08-06 7:26 ` Laszlo Ersek 2013-08-06 7:26 ` Laszlo Ersek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1375716889.2163.12.camel@dabdike.int.hansenpartnership.com \ --to=james.bottomley@hansenpartnership.com \ --cc=bp@alien8.de \ --cc=dwmw2@infradead.org \ --cc=edk2-devel@lists.sourceforge.net \ --cc=gleb@redhat.com \ --cc=lersek@redhat.com \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mjg59@srcf.ucam.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.