All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/7] x86/mkelf32: account for offset when detecting note segment placement
Date: Wed, 19 Mar 2025 15:16:45 +0100	[thread overview]
Message-ID: <Z9rRzRQnHLtUOpQs@macbook.local> (raw)
In-Reply-To: <1dce6993-09d7-4f04-8ccc-908a0a4cc10f@suse.com>

On Wed, Mar 19, 2025 at 11:07:33AM +0100, Jan Beulich wrote:
> On 18.03.2025 18:35, Roger Pau Monne wrote:
> > mkelf32 attempt to check that the program header defined NOTE segment falls
> > inside of the LOAD segment, as the build-id should be loaded for Xen at
> > runtime to check.
> > 
> > However the current code doesn't take into account the LOAD program header
> > segment offset when calculating overlap with the NOTE segment.  This
> > results in incorrect detection, and the following build error:
> > 
> > arch/x86/boot/mkelf32 --notes xen-syms ./.xen.elf32 0x200000 \
> >                `nm xen-syms | sed -ne 's/^\([^ ]*\) . __2M_rwdata_end$/0x\1/p'`
> > Expected .note section within .text section!
> > Offset 4244776 not within 2910364!
> 
> Not your fault, but: Such printing of decimal numbers is of course very
> unhelpful when ...
> 
> > When xen-syms has the following program headers:
> > 
> > Program Header:
> >     LOAD off    0x0000000000200000 vaddr 0xffff82d040200000 paddr 0x0000000000200000 align 2**21
> >          filesz 0x00000000002c689c memsz 0x00000000003f7e20 flags rwx
> >     NOTE off    0x000000000040c528 vaddr 0xffff82d04040c528 paddr 0x000000000040c528 align 2**2
> >          filesz 0x0000000000000024 memsz 0x0000000000000024 flags r--
> 
> ... any half-way sane tool prints such values in hex.
> 
> > --- a/xen/arch/x86/boot/mkelf32.c
> > +++ b/xen/arch/x86/boot/mkelf32.c
> > @@ -358,7 +358,8 @@ int main(int argc, char **argv)
> >          note_sz = in64_phdr.p_memsz;
> >          note_base = in64_phdr.p_vaddr - note_base;
> >  
> > -        if ( in64_phdr.p_offset > dat_siz || offset > in64_phdr.p_offset )
> > +        if ( in64_phdr.p_offset > (offset + dat_siz) ||
> > +             offset > in64_phdr.p_offset )
> 
> This is an improvement, so fine to go in with Andrew's ack, but it still
> doesn't match what the error message suggests is wanted: This checks only
> whether .note starts after .text or ends before .text. A partial overlap,
> which isn't okay either aiui, would go through fine.
> 
> Oh, and - even in your change there's an off-by-1: You mean >= in the lhs
> of the ||.

Hm, I see, it would be better as:

diff --git a/xen/arch/x86/boot/mkelf32.c b/xen/arch/x86/boot/mkelf32.c
index 5f9e7e440e84..f0f406687cea 100644
--- a/xen/arch/x86/boot/mkelf32.c
+++ b/xen/arch/x86/boot/mkelf32.c
@@ -358,11 +358,13 @@ int main(int argc, char **argv)
         note_sz = in64_phdr.p_memsz;
         note_base = in64_phdr.p_vaddr - note_base;
 
-        if ( in64_phdr.p_offset > dat_siz || offset > in64_phdr.p_offset )
+        if ( in64_phdr.p_offset < offset ||
+             in64_phdr.p_offset + in64_phdr.p_filesz > offset + dat_siz )
         {
             fprintf(stderr, "Expected .note section within .text section!\n" \
-                    "Offset %"PRId64" not within %d!\n",
-                    in64_phdr.p_offset, dat_siz);
+                    ".note: [%"PRIx64", %"PRIx64") .text: [%x, %x)\n",
+                    in64_phdr.p_offset, in64_phdr.p_offset + in64_phdr.p_filesz,
+                    offset, offset + dat_siz);
             return 1;
         }
         /* Gets us the absolute offset within the .text section. */



  reply	other threads:[~2025-03-19 14:17 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-18 17:35 [PATCH 0/7] x86: generate xen.efi image with no write-execute sections Roger Pau Monne
2025-03-18 17:35 ` [PATCH 1/7] x86/boot: clarify comment about trampoline_setup usage Roger Pau Monne
2025-03-18 17:45   ` Andrew Cooper
2025-03-19  8:46     ` Roger Pau Monné
2025-03-19 12:22       ` Andrew Cooper
2025-03-18 17:35 ` [PATCH 2/7] x86/mkelf32: account for offset when detecting note segment placement Roger Pau Monne
2025-03-18 17:45   ` Andrew Cooper
2025-03-19 10:07   ` Jan Beulich
2025-03-19 14:16     ` Roger Pau Monné [this message]
2025-03-19 14:33       ` Jan Beulich
2025-03-18 17:35 ` [PATCH 3/7] xen: remove -N from the linker command line Roger Pau Monne
2025-03-18 17:53   ` Andrew Cooper
2025-03-19 10:20   ` Jan Beulich
2025-03-21 16:28   ` Oleksii Kurochko
2025-03-18 17:35 ` [PATCH 4/7] x86/boot: apply trampoline relocations at destination position Roger Pau Monne
2025-03-18 19:05   ` Frediano Ziglio
2025-03-18 19:17     ` Andrew Cooper
2025-03-19 12:00     ` Frediano Ziglio
2025-03-18 20:10   ` [PATCH] x86/boot: Untangle the trampoline copying/entry logic Andrew Cooper
2025-03-19  9:05     ` Roger Pau Monné
2025-03-20 13:59       ` Andrew Cooper
2025-03-18 20:14   ` [PATCH 4/7] x86/boot: apply trampoline relocations at destination position Andrew Cooper
2025-03-18 17:35 ` [PATCH 5/7] x86/mkreloc: remove warning about relocations to RO section Roger Pau Monne
2025-03-18 18:14   ` Andrew Cooper
2025-03-19 10:32   ` Jan Beulich
2025-03-19 10:46     ` Jan Beulich
2025-03-19 10:53       ` Jan Beulich
2025-03-20  8:14       ` Roger Pau Monné
2025-03-20  8:34         ` Jan Beulich
2025-03-20  9:53           ` Jan Beulich
2025-03-20 10:18             ` Jan Beulich
2025-03-20 11:00               ` Andrew Cooper
2025-03-20 11:11                 ` Jan Beulich
2025-03-18 17:35 ` [PATCH 6/7] x86/efi: do not merge all .init sections Roger Pau Monne
2025-03-18 18:08   ` Andrew Cooper
2025-03-19 10:39   ` Jan Beulich
2025-03-18 17:35 ` [PATCH 7/7] xen/build: warn about RWX load segments Roger Pau Monne
2025-03-18 18:07   ` Andrew Cooper

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=Z9rRzRQnHLtUOpQs@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.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.