From: Jan Beulich <jbeulich@suse.com>
To: Frediano Ziglio <frediano.ziglio@cloud.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 3/3] x86: Align output sections for UEFI CA memory mitigation requirements
Date: Tue, 24 Sep 2024 10:14:54 +0200 [thread overview]
Message-ID: <ac8a299d-ec25-431a-aa56-d8a10ca1220a@suse.com> (raw)
In-Reply-To: <CACHz=ZiFyiSaihgTL_rSqfNNag761+1QyAhytQhn5zM6tOUSsw@mail.gmail.com>
On 23.09.2024 18:06, Frediano Ziglio wrote:
> On Mon, Sep 23, 2024 at 4:54 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 19.09.2024 10:00, Frediano Ziglio wrote:
>>> All loadable sections should be page aligned.
>>
>> What about .buildid? .reloc otoh is discardable, and hence presumably okay
>> if mis-aligned.
>
> Currently, internally we have a patch to make ".reloc" not discardaeble.
> The problem is that in case of direct EFI loading, that section is
> used to relocated back to the final location. On bootloaders
> discarding that section, you'll get a crash :-(
Indeed, if such EFI loaders exist we have an issue (I don't think we
actively mark the section discardable, I think that's something the
linker decides).
> Isn't ".buildid" a kind of subsection with the same attributes of
> container section?
In ELF maybe. In the PE binary it's following directly after .rodata,
meaning it typically shares its space with .rodata's last page. (Aiui
in PE/COFF it is illegal for multiple sections to overlap, unlike for
ELF's "segments", i.e. what the program header entries describe.)
> Maybe I have BUILD_ID_EFI not defined?
Possible, albeit would be odd.
Jan
next prev parent reply other threads:[~2024-09-24 8:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 8:00 [PATCH v4 0/3] x86: Satisfy requirements for UEFI CA memory mitigation requirements Frediano Ziglio
2024-09-19 8:00 ` [PATCH v4 1/3] x86: Put trampoline in separate .init.trampoline section Frediano Ziglio
2024-09-23 15:17 ` Jan Beulich
2024-09-23 15:31 ` Frediano Ziglio
2024-09-23 15:42 ` Jan Beulich
2024-09-19 8:00 ` [PATCH v4 2/3] x86: Split output sections for UEFI CA memory mitigation requirements Frediano Ziglio
2024-09-23 15:45 ` Jan Beulich
2024-09-19 8:00 ` [PATCH v4 3/3] x86: Align " Frediano Ziglio
2024-09-23 15:54 ` Jan Beulich
2024-09-23 16:06 ` Frediano Ziglio
2024-09-24 8:14 ` Jan Beulich [this message]
2024-09-24 10:22 ` Frediano Ziglio
2024-09-24 11:09 ` Jan Beulich
2024-09-24 12:17 ` Jan Beulich
2024-09-24 12:22 ` Frediano Ziglio
2024-09-24 13:27 ` Jan Beulich
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=ac8a299d-ec25-431a-aa56-d8a10ca1220a@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=frediano.ziglio@cloud.com \
--cc=roger.pau@citrix.com \
--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 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.