From: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
To: Laszlo Ersek <lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: 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, 5 Aug 2013 18:12:47 +0200 [thread overview]
Message-ID: <20130805161247.GF31845@pd.tnic> (raw)
In-Reply-To: <51FFC19A.1020204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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.
--
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Laszlo Ersek <lersek@redhat.com>
Cc: 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, 5 Aug 2013 18:12:47 +0200 [thread overview]
Message-ID: <20130805161247.GF31845@pd.tnic> (raw)
In-Reply-To: <51FFC19A.1020204@redhat.com>
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.
--
next prev parent reply other threads:[~2013-08-05 16:12 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
[not found] ` <20130731205431.GG4724-fF5Pk5pvG8Y@public.gmane.org>
2013-07-31 20:58 ` Matthew Garrett
2013-07-31 20:58 ` Matthew Garrett
[not found] ` <20130731205858.GA1678-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
2013-07-31 21:51 ` Borislav Petkov
2013-07-31 21:51 ` Borislav Petkov
[not found] ` <20130731215130.GA6087-fF5Pk5pvG8Y@public.gmane.org>
2013-07-31 21:54 ` Matthew Garrett
2013-07-31 21:54 ` Matthew Garrett
[not found] ` <20130731215423.GA2628-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
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
[not found] ` <1375307727.22084.103.camel-Fexsq3y4057IgHVZqg5X0TlWvGAXklZc@public.gmane.org>
2013-08-01 16:49 ` Borislav Petkov
2013-08-01 16:49 ` Borislav Petkov
[not found] ` <20130801164927.GA7445-fF5Pk5pvG8Y@public.gmane.org>
2013-08-05 11:27 ` [edk2] " Laszlo Ersek
2013-08-05 11:27 ` Laszlo Ersek
[not found] ` <51FF8C14.2070405-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-08-05 13:02 ` Borislav Petkov
2013-08-05 13:02 ` Borislav Petkov
[not found] ` <20130805130258.GB31845-fF5Pk5pvG8Y@public.gmane.org>
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
[not found] ` <20130805140306.GD31845-fF5Pk5pvG8Y@public.gmane.org>
2013-08-05 14:27 ` Laszlo Ersek
2013-08-05 14:27 ` Laszlo Ersek
[not found] ` <51FFB660.4060400-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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
[not found] ` <51FFC19A.1020204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-08-05 15:34 ` James Bottomley
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 [this message]
2013-08-05 16:12 ` Borislav Petkov
2013-08-05 16:41 ` Laszlo Ersek
2013-08-05 16:41 ` Laszlo Ersek
[not found] ` <51FFD5B0.9080000-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-08-05 16:47 ` Borislav Petkov
2013-08-05 16:47 ` Borislav Petkov
[not found] ` <20130805164731.GG31845-fF5Pk5pvG8Y@public.gmane.org>
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
[not found] ` <20130805220808.GC14067-fF5Pk5pvG8Y@public.gmane.org>
2013-08-06 14:10 ` Borislav Petkov
2013-08-06 14:10 ` Borislav Petkov
[not found] ` <20130806141036.GD14891-fF5Pk5pvG8Y@public.gmane.org>
2013-08-06 15:31 ` Laszlo Ersek
2013-08-06 15:31 ` Laszlo Ersek
2013-08-07 15:19 ` Borislav Petkov
[not found] ` <20130807151935.GJ17920-fF5Pk5pvG8Y@public.gmane.org>
2013-08-07 17:23 ` Andrew Fish
2013-08-07 17:23 ` Andrew Fish
[not found] ` <CCFD3CBD-62B0-4046-B96D-18CB1A815F72-2kanFRK1NckAvxtiuMwx3w@public.gmane.org>
2013-08-07 20:19 ` Matt Fleming
2013-08-07 20:19 ` Matt Fleming
[not found] ` <20130807201908.GG2515-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
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
[not found] ` <D5982201-6DC4-469F-812A-74A8402ADEE9-2kanFRK1NckAvxtiuMwx3w@public.gmane.org>
2013-08-08 10:17 ` Matt Fleming
2013-08-08 10:17 ` Matt Fleming
[not found] ` <20130808101730.GJ2515-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2013-08-08 13:46 ` Andrew Fish
2013-08-08 13:46 ` Andrew Fish
[not found] ` <1AEC7AA8-D49E-485F-A634-31B4F0D07083-2kanFRK1NckAvxtiuMwx3w@public.gmane.org>
2013-09-02 8:19 ` Matt Fleming
2013-09-02 8:19 ` Matt Fleming
2013-09-13 20:38 ` jerry.hoemann-VXdhtT5mjnY
2013-09-13 20:38 ` jerry.hoemann
[not found] ` <20130913203812.GA312-dMAi7lA+vBPDUbYHzcRnttBPR1lH4CV8@public.gmane.org>
2013-09-16 10:59 ` Matt Fleming
2013-09-16 10:59 ` Matt Fleming
[not found] ` <20130916105920.GB2697-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2013-09-16 11:50 ` Laszlo Ersek
2013-09-16 11:50 ` Laszlo Ersek
[not found] ` <5236F096.8040702-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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
[not found] ` <523730F2.40408-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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-VXdhtT5mjnY
2013-09-18 19:24 ` jerry.hoemann
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
[not found] ` <5202889C.2080608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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
[not found] ` <2DBE3EA4-E321-4A7B-B9AF-EDE55BC2E358-2kanFRK1NckAvxtiuMwx3w@public.gmane.org>
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
[not found] ` <52001B04.2050806-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2013-08-05 21:41 ` Borislav Petkov
2013-08-05 21:41 ` Borislav Petkov
[not found] ` <20130805214140.GB14067-fF5Pk5pvG8Y@public.gmane.org>
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
[not found] ` <52001F6B.4000800-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-08-05 22:52 ` James Bottomley
2013-08-05 22:52 ` James Bottomley
[not found] ` <1375743157.18481.14.camel-sFMDBYUN5F8GjUHQrlYNx2Wm91YjaHnnhRte9Li2A+AAvxtiuMwx3w@public.gmane.org>
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=20130805161247.GF31845@pd.tnic \
--to=bp-gina5biwoiwzqb+pc5nmwq@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=edk2-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=gleb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.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: link
Be 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.