From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Bob Eshleman <bobbyeshleman@gmail.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Ian Jackson <iwj@xenproject.org>, Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 2/5] xen/x86: manually build xen.mb.efi binary
Date: Tue, 18 May 2021 19:46:33 +0200 [thread overview]
Message-ID: <20210518174633.spo5kmgcbuo6dg5k@tomti.i.net-space.pl> (raw)
In-Reply-To: <ee89a22d-5f46-51ed-4c46-63cfc60cbafc@suse.com>
On Mon, May 17, 2021 at 03:24:28PM +0200, Jan Beulich wrote:
> On 17.05.2021 15:20, Daniel Kiper wrote:
> > On Mon, May 17, 2021 at 08:48:32AM +0200, Jan Beulich wrote:
> >> On 07.05.2021 22:26, Bob Eshleman wrote:
> >>> What is your intuition WRT the idea that instead of trying add a PE/COFF hdr
> >>> in front of Xen's mb2 bin, we instead go the route of introducing valid mb2
> >>> entry points into xen.efi?
> >>
> >> At the first glance I think this is going to be less intrusive, and hence
> >> to be preferred. But of course I haven't experimented in any way ...
> >
> > When I worked on this a few years ago I tried that way. Sadly I failed
> > because I was not able to produce "linear" PE image using binutils
> > exiting that days.
>
> What is a "linear" PE image?
The problem with Multiboot family protocols is that all code and data
sections have to be glued together in the image and as such loaded into
the memory (IIRC BSS is an exception but it has to live behind the
image). So, you cannot use PE image which has different representation
in file and memory. IIRC by default at least code and data sections in
xen.efi have different sizes in PE file and in memory. I tried to fix
that using linker script and objcopy but it did not work. Sadly I do
not remember the details but there is pretty good chance you can find
relevant emails in Xen-devel archive with me explaining what kind of
problems I met.
> > Maybe
> > newer binutils are more flexible and will be able to produce a PE image
> > with properties required by Multiboot2 protocol.
>
> Isn't all you need the MB2 header within the first so many bytes of the
> (disk) image? Or was it the image as loaded into memory? Both should be
> possible to arrange for.
IIRC Multiboot2 protocol requires the header in first 32 kiB of an image.
So, this is not a problem.
Daniel
next prev parent reply other threads:[~2021-05-18 17:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-22 0:51 [PATCH v3 0/5] Support Secure Boot for multiboot2 Xen Bobby Eshleman
2021-01-22 0:51 ` [PATCH v3 1/5] xen: add XEN_BUILD_POSIX_TIME Bobby Eshleman
2021-01-22 11:27 ` Jan Beulich
2021-01-22 21:57 ` Bobby Eshleman
2021-01-25 8:58 ` Jan Beulich
2021-01-22 0:51 ` [PATCH v3 2/5] xen/x86: manually build xen.mb.efi binary Bobby Eshleman
2021-03-15 13:36 ` Jan Beulich
2021-05-07 20:26 ` Bob Eshleman
2021-05-17 6:48 ` Jan Beulich
2021-05-17 13:20 ` Daniel Kiper
2021-05-17 13:24 ` Jan Beulich
2021-05-18 17:46 ` Daniel Kiper [this message]
2021-05-19 9:29 ` Jan Beulich
2021-05-19 12:48 ` Daniel Kiper
2021-05-19 14:35 ` Jan Beulich
2021-06-09 13:18 ` Daniel Kiper
2021-06-09 13:45 ` Jan Beulich
2021-01-22 0:51 ` [PATCH v3 3/5] xen/x86: add some addresses to the Multiboot header Bobby Eshleman
2021-03-15 15:05 ` Jan Beulich
2021-01-22 0:51 ` [PATCH v3 4/5] xen/x86: add some addresses to the Multiboot2 header Bobby Eshleman
2021-02-23 9:04 ` Roger Pau Monné
2021-02-23 18:07 ` Bob Eshleman
2021-01-22 0:51 ` [PATCH v3 5/5] xen/x86/efi: Verify dom0 kernel with SHIM_LOCK protocol in efi_multiboot2() Bobby Eshleman
2021-03-16 15:08 ` Jan Beulich
2021-01-22 9:39 ` [PATCH v3 0/5] Support Secure Boot for multiboot2 Xen Jan Beulich
2021-01-22 21:18 ` Bobby Eshleman
2021-01-25 8:52 ` Jan Beulich
2021-02-22 18:04 ` Bobby Eshleman
2021-02-23 7:16 ` Jan Beulich
2021-02-23 18:00 ` Bob Eshleman
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=20210518174633.spo5kmgcbuo6dg5k@tomti.i.net-space.pl \
--to=daniel.kiper@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=bobbyeshleman@gmail.com \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).