From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 02/11] x86/mkreloc: fix obtaining PE image base address
Date: Tue, 8 Apr 2025 13:21:19 +0200 [thread overview]
Message-ID: <Z_UGr0A8LetHDJvB@macbook.lan> (raw)
In-Reply-To: <a14a7a42-cf7e-463b-a87d-e302ce32371b@suse.com>
On Wed, Apr 02, 2025 at 09:46:53AM +0200, Jan Beulich wrote:
> On 01.04.2025 16:17, Jan Beulich wrote:
> > On 01.04.2025 15:08, Roger Pau Monne wrote:
> >> The base address is in the pe32_opt_hdr, not after it.
>
> Which is a result of pe.h munging both the optional and the NT header into
> a single structure.
>
> >> Previous to commit f7f42accbbbb the base was read standalone (as the first
> >> field of pe32_opt_hdr). However with the addition of reading the full
> >> contents of pe32_opt_hdr, such read will also fetch the base. The current
> >> attempt to read the base after pe32_opt_hdr is bogus, and could only work
> >> if the file cursor is repositioned using lseek(), but there's no need for
> >> that as the data is already fetched in pe32_opt_hdr.
> >
> > Yes, but: How did things work at all then with this bug?
>
> It simply didn't. We got away only because apparently no-one tried a build
> with a linker old enough for this tool to come into play.
>
> I'd like to suggest the replacement patch below, though.
>
> Jan
>
> x86/EFI: correct mkreloc header (field) reading
>
> With us now reading the full combined optional and NT headers, the
> subsequent reading of (and seeking to) NT header fields is wrong. Since
> PE32 and PE32+ NT headers are different anyway (beyond the image base
> oddity extending across both headers), switch to using a union. This
> allows to fetch the image base more directly then.
>
> Additionally add checking to map_section(), which would have caught at
> least the wrong (zero) image size that we previously used.
>
> Fixes: f7f42accbbbb ("x86/efi: Use generic PE/COFF structures")
> Reported-by: Roger Pau Monné <roger.pau@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Of the two checks added to map_section(), the 1st ends up being largely
> redundant with the 2nd one. Should we use just the latter?
>
> Also sanity checking the image base would be possible, but more
> cumbersome if we wanted to check moret than just "is in high half of
> address space). Therefore I've left out doing so.
We could likely check that image_base >= XEN_VIRT_START? However I'm
not sure how easy it is to make XEN_VIRT_START available to mkreloc.
> --- a/xen/arch/x86/efi/mkreloc.c
> +++ b/xen/arch/x86/efi/mkreloc.c
> @@ -28,14 +28,16 @@ static void usage(const char *cmd, int r
> static unsigned int load(const char *name, int *handle,
> struct section_header **sections,
> uint_fast64_t *image_base,
> - uint32_t *image_size,
> + uint_fast32_t *image_size,
> unsigned int *width)
> {
> int in = open(name, O_RDONLY);
> struct mz_hdr mz_hdr;
> struct pe_hdr pe_hdr;
> - struct pe32_opt_hdr pe32_opt_hdr;
> - uint32_t base;
> + union {
> + struct pe32_opt_hdr pe;
> + struct pe32plus_opt_hdr pep;
> + } pe32_opt_hdr;
>
> if ( in < 0 ||
> read(in, &mz_hdr, sizeof(mz_hdr)) != sizeof(mz_hdr) )
> @@ -54,31 +56,40 @@ static unsigned int load(const char *nam
>
> if ( lseek(in, mz_hdr.peaddr, SEEK_SET) < 0 ||
> read(in, &pe_hdr, sizeof(pe_hdr)) != sizeof(pe_hdr) ||
> - read(in, &pe32_opt_hdr, sizeof(pe32_opt_hdr)) != sizeof(pe32_opt_hdr) ||
> - read(in, &base, sizeof(base)) != sizeof(base) ||
> - /*
> - * Luckily the image size field lives at the
> - * same offset for both formats.
> - */
> - lseek(in, 24, SEEK_CUR) < 0 ||
> - read(in, image_size, sizeof(*image_size)) != sizeof(*image_size) )
> + (read(in, &pe32_opt_hdr.pe, sizeof(pe32_opt_hdr.pe)) !=
> + sizeof(pe32_opt_hdr.pe)) )
> {
> perror(name);
> exit(3);
> }
>
> switch ( (pe_hdr.magic == PE_MAGIC &&
> - pe_hdr.opt_hdr_size > sizeof(pe32_opt_hdr)) *
> - pe32_opt_hdr.magic )
> + pe_hdr.opt_hdr_size > sizeof(pe32_opt_hdr.pe)) *
> + pe32_opt_hdr.pe.magic )
> {
> case PE_OPT_MAGIC_PE32:
> *width = 32;
> - *image_base = base;
> + *image_base = pe32_opt_hdr.pe.image_base;
> + *image_size = pe32_opt_hdr.pe.image_size;
> break;
> case PE_OPT_MAGIC_PE32PLUS:
> - *width = 64;
> - *image_base = ((uint64_t)base << 32) | pe32_opt_hdr.data_base;
> - break;
> + if ( pe_hdr.opt_hdr_size > sizeof(pe32_opt_hdr.pep) )
> + {
> + if ( read(in,
> + &pe32_opt_hdr.pe + 1,
> + sizeof(pe32_opt_hdr.pep) - sizeof(pe32_opt_hdr.pe)) !=
> + sizeof(pe32_opt_hdr.pep) - sizeof(pe32_opt_hdr.pe) )
> + {
> + perror(name);
> + exit(3);
> + }
> +
> + *width = 64;
> + *image_base = pe32_opt_hdr.pep.image_base;
> + *image_size = pe32_opt_hdr.pep.image_size;
> + break;
> + }
Since you are already refactoring much of this code, won't it be
clearer to fetch the header inside of the switch cases. So that
there's a single read call for each header type?
> + /* Fall through. */
> default:
> fprintf(stderr, "%s: Wrong PE file format\n", name);
> exit(3);
> @@ -108,11 +119,28 @@ static unsigned int load(const char *nam
> static long page_size;
>
> static const void *map_section(const struct section_header *sec, int in,
> - const char *name)
> + const char *name, uint_fast32_t image_size)
> {
> const char *ptr;
> unsigned long offs;
>
> + if ( sec->rva > image_size )
Strictly, should this be >=, as rva is a position, and image_size is a
size, so the last allowed bit would be image_size - 1?
Thanks, Roger.
next prev parent reply other threads:[~2025-04-08 11:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 13:08 [PATCH v2 00/11] x86/EFI: prevent write-execute sections Roger Pau Monne
2025-04-01 13:08 ` [PATCH v2 01/11] automation/dockers: add to README how to rebuild all containers Roger Pau Monne
2025-04-01 13:25 ` Andrew Cooper
2025-04-01 23:08 ` Stefano Stabellini
2025-04-01 13:08 ` [PATCH v2 02/11] x86/mkreloc: fix obtaining PE image base address Roger Pau Monne
2025-04-01 14:01 ` Andrew Cooper
2025-04-01 14:17 ` Jan Beulich
2025-04-02 7:46 ` Jan Beulich
2025-04-08 11:21 ` Roger Pau Monné [this message]
2025-04-08 12:34 ` Jan Beulich
2025-04-10 7:20 ` Roger Pau Monné
2025-04-10 7:41 ` Jan Beulich
2025-04-01 13:08 ` [PATCH v2 03/11] x86/mkreloc: use the string table to get names Roger Pau Monne
2025-04-01 15:50 ` Jan Beulich
2025-04-02 7:42 ` Jan Beulich
2025-04-01 13:08 ` [PATCH v2 04/11] x86/mkreloc: print the linear address of relocations to read-only sections Roger Pau Monne
2025-04-01 15:55 ` Jan Beulich
2025-04-01 13:08 ` [PATCH v2 05/11] xen: remove -N from the linker command line Roger Pau Monne
2025-04-02 10:28 ` Julien Grall
2025-04-01 13:08 ` [PATCH v2 06/11] x86/efi: discard .text.header for PE binary Roger Pau Monne
2025-04-01 13:18 ` Jan Beulich
2025-04-01 13:22 ` Andrew Cooper
2025-04-01 13:08 ` [PATCH v2 07/11] x86/efi: discard multiboot related entry code " Roger Pau Monne
2025-04-01 16:02 ` Jan Beulich
2025-04-01 13:08 ` [PATCH v2 08/11] x86/boot: place trampoline code in a non-execute section Roger Pau Monne
2025-04-01 13:49 ` Andrew Cooper
2025-04-02 9:47 ` Jan Beulich
2025-04-01 13:08 ` [PATCH v2 09/11] x86/efi: avoid a relocation in efi_arch_post_exit_boot() Roger Pau Monne
2025-04-02 10:23 ` Jan Beulich
2025-04-01 13:08 ` [PATCH v2 10/11] x86/efi: do not merge all .init sections Roger Pau Monne
2025-04-02 10:28 ` Jan Beulich
2025-04-01 13:08 ` [PATCH v2 11/11] automation/x86: add a xen.efi test with a strict NX OVMF build Roger Pau Monne
2025-04-01 14:23 ` Andrew Cooper
2025-04-01 13:13 ` [PATCH v2 00/11] x86/EFI: prevent write-execute sections Jan Beulich
2025-04-01 13:26 ` Roger Pau Monné
2025-04-01 13:58 ` Jan Beulich
2025-04-07 14:04 ` Jan Beulich
2025-04-08 7:56 ` Roger Pau Monné
2025-04-08 8:18 ` 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=Z_UGr0A8LetHDJvB@macbook.lan \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=dpsmith@apertussolutions.com \
--cc=jbeulich@suse.com \
--cc=marmarek@invisiblethingslab.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.