|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/6] Align all sections to 4KB
On 13.06.2026 13:20, Frediano Ziglio wrote:
> 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.
>
> 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?
s/all/relevant/ (or some such) in the subject and then largely what you say
above as part of the description.
Jan
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |