From: Arvind Sankar <nivedita@alum.mit.edu>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
linux-efi <linux-efi@vger.kernel.org>,
Laszlo Ersek <lersek@redhat.com>,
Leif Lindholm <leif@nuviainc.com>,
Peter Jones <pjones@redhat.com>,
Matthew Garrett <mjg59@google.com>,
Alexander Graf <agraf@csgraf.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Daniel Kiper <daniel.kiper@oracle.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [RFC PATCH 1/3] efi/x86: Use symbolic constants in PE header instead of bare numbers
Date: Thu, 20 Feb 2020 14:51:57 -0500 [thread overview]
Message-ID: <20200220195157.GA2483987@rani.riverdale.lan> (raw)
In-Reply-To: <CAKv+Gu_QiXsJyR0X4au+r75DFoQmSUp38+J7BuD3HAH+rJ9gHQ@mail.gmail.com>
On Thu, Feb 20, 2020 at 06:32:39PM +0100, Ard Biesheuvel wrote:
> On Thu, 20 Feb 2020 at 18:28, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> >
> > The .text section contains data as well. Shouldn't it be marked
> > IMAGE_SCN_MEM_WRITE also?
> >
>
> Another good point. For ARM and arm64, I actually changed this into
> split R-X and RW- sections, in case the loader decides to honour these
> attributes (which it should imo)
>
> So yes, we should either add IMAGE_SCN_MEM_WRITE, or add a .data
> section (although we probably don't have the space for that).
>
> Another thing I wondered was whether we really need the .reloc
> section. We don't have one on ARM, and it works fine with the existing
> EDK2 loader.
> Peter: any idea whether the issue with .reloc you pointed out to me
> the other day still exists in EDK2 today?
Is there any reason we couldn't combine .setup + .text as R-X, then
.reloc, then .data + .bss as RW-? That would leave room for the new
.compat section then even without removing .reloc.
Although if the loader actually honored the non-writable setting,
efi_relocate_kernel has to be done unconditionally. It currently happens
to be unconditional if you come in via PE loader, since we don't set
ImageBase to tell it our preferred address, and even if we did, the
existence of .setup means startup32 isn't at that address.
next prev parent reply other threads:[~2020-02-20 19:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 11:06 [RFC PATCH 0/3] efi: put an API version number in the PE/COFF header Ard Biesheuvel
2020-02-20 11:06 ` [RFC PATCH 1/3] efi/x86: Use symbolic constants in PE header instead of bare numbers Ard Biesheuvel
2020-02-20 17:28 ` Arvind Sankar
2020-02-20 17:32 ` Ard Biesheuvel
2020-02-20 18:04 ` Arvind Sankar
2020-02-20 18:11 ` Arvind Sankar
2020-02-20 18:14 ` Ard Biesheuvel
2020-02-20 19:33 ` Arvind Sankar
2020-02-20 19:51 ` Arvind Sankar [this message]
2020-02-20 21:22 ` Ard Biesheuvel
2020-02-20 22:04 ` Arvind Sankar
2020-02-20 11:06 ` [RFC PATCH 2/3] efi/libstub: Introduce symbolic constants for the stub major/minor version Ard Biesheuvel
2020-02-20 11:06 ` [RFC PATCH 3/3] efi: Bump the Linux EFI stub major version number to #1 Ard Biesheuvel
2020-02-20 13:53 ` [RFC PATCH 0/3] efi: put an API version number in the PE/COFF header Daniel Kiper
2020-02-20 14:55 ` Heinrich Schuchardt
2020-02-20 19:29 ` Ard Biesheuvel
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=20200220195157.GA2483987@rani.riverdale.lan \
--to=nivedita@alum.mit.edu \
--cc=James.Bottomley@hansenpartnership.com \
--cc=agraf@csgraf.de \
--cc=ardb@kernel.org \
--cc=daniel.kiper@oracle.com \
--cc=ilias.apalodimas@linaro.org \
--cc=leif@nuviainc.com \
--cc=lersek@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=mjg59@google.com \
--cc=pjones@redhat.com \
--cc=xypron.glpk@gmx.de \
/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).