From: pjones@redhat.com (Peter Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] arm64/efi: efistub: jump to 'stext' directly, not through the header
Date: Fri, 10 Oct 2014 09:53:45 -0400 [thread overview]
Message-ID: <20141010135344.GB14660@fenchurch.internal.datastacks.com> (raw)
In-Reply-To: <CAFECyb9Tz2Fo2ix0VYiM7WPeie7C=woiVwyQtR4aH_HPcLwkOg@mail.gmail.com>
On Thu, Oct 09, 2014 at 04:20:19PM -0700, Roy Franz wrote:
> I think we'll also run into some alignment issues if the loader really just
> loads the section ( we just have the one) rather than the whole file.
> From reviewing the PE/COFF spec again we violate the relationship
> between FileAlignment and SectionAlignment.
It's hard to pin down exactly whose burden this is - clearly the RVAs
and the File Addresses in the binary are supposed to jive with
SectionAlignment and FileAlignment, respectively, but if they don't,
it's unclear what a loader should do about it. I've got some (x86)
hardware where LoadImage() rejects the binary entirely in this case, but
the code in tiano doesn't seem to care. Our loader code in shim ignores
both fields entirely - once we've checked validity in terms of overlap
and boundaries, we happily give sections whatever offset they've
requested. I suppose on some machines that may mean that a malformed
binary gets a /fault/ pretty quickly. I'll add checks for those
alignments in shim 0.9 , release date TBD.
So because of that x86 machine that does error out, I've got some
different values here:
https://github.com/vathpela/shim/blob/manual-headers/crt0-efi-x86_64.S#L72
than Ard does in his Aarch64 headers. There are some other things
wrong on that branch because I didn't understand well enough while
writing some of it - it's basically still there for reference, I don't
anticipate ever shipping it.
--
Peter
next prev parent reply other threads:[~2014-10-10 13:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 14:11 [PATCH v3] arm64/efi: efistub: jump to 'stext' directly, not through the header Ard Biesheuvel
2014-10-09 17:23 ` Mark Rutland
2014-10-09 19:03 ` Ard Biesheuvel
2014-10-09 22:19 ` Mark Salter
2014-10-09 23:20 ` Roy Franz
2014-10-10 6:30 ` Ard Biesheuvel
2014-10-10 14:14 ` Mark Salter
2014-10-10 14:28 ` Ard Biesheuvel
2014-10-10 13:53 ` Peter Jones [this message]
2014-10-10 10:49 ` Mark Rutland
2014-10-10 11:52 ` Ard Biesheuvel
2014-10-10 12:19 ` Mark Rutland
2014-10-10 12:31 ` Ard Biesheuvel
2014-10-10 13:03 ` Mark Rutland
2014-10-10 13:27 ` Ard Biesheuvel
2014-10-10 14:02 ` Mark Rutland
2014-10-10 15:38 ` Roy Franz
2014-10-10 15:52 ` 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=20141010135344.GB14660@fenchurch.internal.datastacks.com \
--to=pjones@redhat.com \
--cc=linux-arm-kernel@lists.infradead.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).