|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/6] Align all sections to 4KB
On Thu, 11 Jun 2026 at 16:18, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 11.06.2026 16:49, Frediano Ziglio wrote:
> > On Wed, 10 Jun 2026 at 10:43, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>
> >> On 06.06.2026 18:02, Frediano Ziglio wrote:
> >>> Frediano
> >>>
> >>> On Fri, 5 Jun 2026 at 08:45, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>>>
> >>>> On 04.06.2026 12:16, Frediano Ziglio wrote:
> >>>>> On Tue, 2 Jun 2026 at 13:09, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>>>>> On 29.05.2026 17:35, Frediano Ziglio wrote:
> >>>>>>> --- a/xen/arch/x86/xen.lds.S
> >>>>>>> +++ b/xen/arch/x86/xen.lds.S
> >>>>>>> @@ -162,8 +162,8 @@ SECTIONS
> >>>>>>> __note_gnu_build_id_end = .;
> >>>>>>> } PHDR(note) PHDR(text)
> >>>>>>> #elif defined(BUILD_ID_EFI)
> >>>>>>> - /* Workaround bug in binutils < 2.36 */
> >>>>>>> - . = ALIGN(32);
> >>>>>>> + /* align to satisfy UEFI CA memory mitigation */
> >>>>>>> + . = ALIGN(PAGE_SIZE);
> >>>>>>> DECL_SECTION(.buildid) {
> >>>>>>> __note_gnu_build_id_start = .;
> >>>>>>> *(.buildid)
> >>>>>>> @@ -330,6 +330,7 @@ SECTIONS
> >>>>>>> __2M_rwdata_end = ALIGN(SECTION_ALIGN);
> >>>>>>>
> >>>>>>> #ifdef EFI
> >>>>>>> + . = ALIGN(PAGE_SIZE);
> >>>>>>> .reloc ALIGN(4) : {
> >>>>>>> __base_relocs_start = .;
> >>>>>>> *(.reloc)
> >>>>>>> @@ -355,6 +356,7 @@ SECTIONS
> >>>>>>> VIRT_START &= 0;
> >>>>>>> ALT_START &= 0;
> >>>>>>>
> >>>>>>> + . = ALIGN(PAGE_SIZE);
> >>>>>>> .sbat (NOLOAD) : { *(.sbat) }
> >>>>>>> #elif defined(XEN_BUILD_EFI)
> >>>>>>> /*
> >>>>>>
> >>>>>> You say "all sections" in the title, yet this is not covering e.g.
> >>>>>> debug
> >>>>>> info.
> >>>>>
> >>>>> I will change to "all loadable sections". debug sections are not
> >>>>> loadable so they don't cause an issue.
> >>>>
> >>>> Please try to be precise there, as some aspects are subtle. As per my
> >>>> understanding, like .reloc all .debug_* are loadable (and may be loaded).
> >>>> The IMAGE_SCN_MEM_DISCARDABLE flag merely means they can be discarded at
> >>>> a certain point after image loading (for .reloc in particular: after
> >>>> relocations were processed).
> >>>
> >>> No, debug sections are not loadable, for instance, in a random
> >>> executable I found:
> >>>
> >>> Sections:
> >>> Idx Name Size VMA LMA File off
> >>> Algn
> >>> 0 .text 0000c7f8 0000000140001000 0000000140001000 00000600
> >>> 2**4
> >>> CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
> >>> 1 .data 00000250 000000014000e000 000000014000e000 0000ce00
> >>> 2**4
> >>> CONTENTS, ALLOC, LOAD, DATA
> >>> 2 .rdata 00002c70 000000014000f000 000000014000f000 0000d200
> >>> 2**4
> >>> CONTENTS, ALLOC, LOAD, READONLY, DATA
> >>> 3 .pdata 00000654 0000000140012000 0000000140012000 00010000
> >>> 2**2
> >>> CONTENTS, ALLOC, LOAD, READONLY, DATA
> >>> 4 .xdata 00000630 0000000140013000 0000000140013000 00010800
> >>> 2**2
> >>> CONTENTS, ALLOC, LOAD, READONLY, DATA
> >>> 5 .bss 00001ec0 0000000140014000 0000000140014000 00000000
> >>> 2**4
> >>> ALLOC
> >>> 6 .idata 00000c88 0000000140016000 0000000140016000 00011000
> >>> 2**2
> >>> CONTENTS, ALLOC, LOAD, DATA
> >>> 7 .CRT 00000060 0000000140017000 0000000140017000 00011e00
> >>> 2**2
> >>> CONTENTS, ALLOC, LOAD, DATA
> >>> 8 .tls 00000010 0000000140018000 0000000140018000 00012000
> >>> 2**2
> >>> CONTENTS, ALLOC, LOAD, DATA
> >>> 9 .reloc 0000009c 0000000140019000 0000000140019000 00012200
> >>> 2**2
> >>> CONTENTS, ALLOC, LOAD, READONLY, DATA
> >>> 10 .debug_aranges 00000150 000000014001a000 000000014001a000 00012400
> >>> 2**0
> >>> CONTENTS, READONLY, DEBUGGING
> >>> 11 .debug_info 0000d5e4 000000014001b000 000000014001b000 00012600
> >>> 2**0
> >>> CONTENTS, READONLY, DEBUGGING
> >>> 12 .debug_abbrev 000014de 0000000140029000 0000000140029000 0001fc00
> >>> 2**0
> >>> CONTENTS, READONLY, DEBUGGING
> >>> 13 .debug_line 00001a36 000000014002b000 000000014002b000 00021200
> >>> 2**0
> >>> CONTENTS, READONLY, DEBUGGING
> >>> 14 .debug_frame 00000f40 000000014002d000 000000014002d000 00022e00
> >>> 2**0
> >>> CONTENTS, READONLY, DEBUGGING
> >>> 15 .debug_str 000003a0 000000014002e000 000000014002e000 00023e00
> >>> 2**0
> >>> CONTENTS, READONLY, DEBUGGING
> >>> 16 .debug_line_str 00000a76 000000014002f000 000000014002f000
> >>> 00024200 2**0
> >>> CONTENTS, READONLY, DEBUGGING
> >>> 17 .debug_loclists 0000174a 0000000140030000 0000000140030000
> >>> 00024e00 2**0
> >>> CONTENTS, READONLY, DEBUGGING
> >>> 18 .debug_rnglists 0000039c 0000000140032000 0000000140032000
> >>> 00026600 2**0
> >>> CONTENTS, READONLY, DEBUGGING
> >>
> >> That's derived from libfd's internal representation, which means nothing at
> >> all to the loader processing the image. If your objdump is suitably
> >> enabled,
> >> try using its -P option.
> >>
> >> Jan
> >
> > You are right, I got
> >
> > Section headers (at offset 0x00000188):
> > # Name paddr vaddr size scnptr relptr lnnoptr nrel
> > nlnno
> > 1 .text 0000c7f8 00001000 0000c800 00000600 00000000 00000000 0 > > 0
> > Flags: 60000060: EXECUTE,READ,CODE,INITIALIZED DATA
> > 2 .data 00000250 0000e000 00000400 0000ce00 00000000 00000000 0 > > 0
> > Flags: c0000040: READ,WRITE,INITIALIZED DATA
> > 3 .rdata 00002c70 0000f000 00002e00 0000d200 00000000 00000000 0 > > 0
> > Flags: 40000040: READ,INITIALIZED DATA
> > 4 .pdata 00000654 00012000 00000800 00010000 00000000 00000000 0 > > 0
> > Flags: 40000040: READ,INITIALIZED DATA
> > 5 .xdata 00000630 00013000 00000800 00010800 00000000 00000000 0 > > 0
> > Flags: 40000040: READ,INITIALIZED DATA
> > 6 .bss 00001ec0 00014000 00000000 00000000 00000000 00000000 0 > > 0
> > Flags: c0000080: READ,WRITE,UNINITIALIZED DATA
> > 7 .idata 00000c88 00016000 00000e00 00011000 00000000 00000000 0 > > 0
> > Flags: c0000040: READ,WRITE,INITIALIZED DATA
> > 8 .CRT 00000060 00017000 00000200 00011e00 00000000 00000000 0 > > 0
> > Flags: c0000040: READ,WRITE,INITIALIZED DATA
> > 9 .tls 00000010 00018000 00000200 00012000 00000000 00000000 0 > > 0
> > Flags: c0000040: READ,WRITE,INITIALIZED DATA
> > 10 .reloc 0000009c 00019000 00000200 00012200 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> > 11 /4 00000150 0001a000 00000200 00012400 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> > 12 /19 0000d5e4 0001b000 0000d600 00012600 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> > 13 /31 000014de 00029000 00001600 0001fc00 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> > 14 /45 00001a36 0002b000 00001c00 00021200 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> > 15 /57 00000f40 0002d000 00001000 00022e00 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> > 16 /70 000003a0 0002e000 00000400 00023e00 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> > 17 /81 00000a76 0002f000 00000c00 00024200 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> > 18 /97 0000174a 00030000 00001800 00024e00 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> > 19 /113 0000039c 00032000 00000400 00026600 00000000 00000000 0 > > 0
> > Flags: 42000040: DISCARDABLE,READ,INITIALIZED DATA
> >
> > I suppose I will change to simply "Align some sections to 4KB"
>
> "Some" is imo going to be too imprecise. Please qualify which sections you
> intend to align. If new sections need adding in the future, this then can
> guide people as to whether those may also need aligning.
>
> Jan
The main issue is that sections with different permissions must be in
separate sections.
In the case of debug sections they are contiguous and have the same
permissions so it's not an issue (although better to strip them off).
Any suggestions on how to describe this?
Frediano
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |