Unaligned accesses when loading modules

Unaligned accesses when loading modules

[Mikulas Patocka]

Hi

On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when 
a module is loaded. The warnings are caused by the fact that the 
.gnu.linkonce.this_module section is not aligned to the appropriate 
boundary. If I dump the module content with "objdump -h configs.ko", I get 
this. Note that the .gnu.linkonce.this_module has "File off 000042d2" and 
"Algn 2**4".

On x86-64, the same misalignment can be seen, but it doesn't cause 
warnings because unaligned pointers are handled in hardware.

This seems to be a bug in the linker, because when I compile an old kernel 
with a new linker, I also get the misalignment. Do you have an idea how to 
work around this bug?

Mikulas


kernel-6.12.9, binutils from Debian ports:

configs.ko:     file format elf64-hppa-linux

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00000040  0000000000000000  0000000000000000  00000040  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .init.text    00000070  0000000000000000  0000000000000000  00000080  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .exit.text    00000028  0000000000000000  0000000000000000  000000f0  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  3 .rodata       00004015  0000000000000000  0000000000000000  00000118  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .rodata.str1.8 00000010  0000000000000000  0000000000000000  0000412d  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .PARISC.unwind 00000030  0000000000000000  0000000000000000  0000413d  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  6 .modinfo      000000a1  0000000000000000  0000000000000000  0000416d  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .note.gnu.build-id 00000024  0000000000000000  0000000000000000  0000420e  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .note.Linux   00000030  0000000000000000  0000000000000000  00004232  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .data         00000000  0000000000000030  0000000000000030  00004262  2**0
                  CONTENTS, ALLOC, LOAD, DATA
 10 .exit.data    00000008  0000000000000000  0000000000000000  00004262  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 11 .init.data    00000008  0000000000000000  0000000000000000  0000426a  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 12 .data.rel.ro  00000060  0000000000000000  0000000000000000  00004272  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 13 .gnu.linkonce.this_module 000002d0  0000000000000000  0000000000000000  000042d2  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, DATA, LINK_ONCE_DISCARD
 14 .bss          00000000  0000000000000000  0000000000000000  000045a2  2**0
                  ALLOC
 15 .comment      00000039  0000000000000000  0000000000000000  000045a2  2**0
                  CONTENTS, READONLY
 16 .note.GNU-stack 00000000  0000000000000000  0000000000000000  000045db  2**0
                  CONTENTS, READONLY

With the kernel 6.10, I get this - the ".gnu.linkonce.this_module" 
sections has "File off 00004210" and "Algn 2**4" - so, it is properly 
aligned.

kernel 6.10, older binutils:

configs.ko:     file format elf64-hppa-linux

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .note.gnu.build-id 00000024  0000000000000000  0000000000000000  00000040  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.Linux   00000030  0000000000000000  0000000000000000  00000064  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .text         00000040  0000000000000000  0000000000000000  00000098  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  3 .init.text    00000070  0000000000000000  0000000000000000  000000d8  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  4 .exit.text    00000028  0000000000000000  0000000000000000  00000148  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  5 .rodata       00003f45  0000000000000000  0000000000000000  00000170  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .rodata.str1.8 00000010  0000000000000000  0000000000000000  000040b8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .PARISC.unwind 00000030  0000000000000000  0000000000000000  000040c8  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  8 .modinfo      000000a1  0000000000000000  0000000000000000  000040f8  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .data         00000007  00000000000000a1  00000000000000a1  00004199  2**0
                  CONTENTS, ALLOC, LOAD, DATA
 10 .exit.data    00000008  0000000000000000  0000000000000000  000041a0  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 11 .init.data    00000008  0000000000000000  0000000000000000  000041a8  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 12 .data.rel.ro  00000060  0000000000000000  0000000000000000  000041b0  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
 13 .gnu.linkonce.this_module 000002d0  0000000000000000  0000000000000000  00004210  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, DATA, LINK_ONCE_DISCARD
 14 .bss          00000000  0000000000000000  0000000000000000  000044e0  2**0
                  ALLOC
 15 .comment      00000026  0000000000000000  0000000000000000  000044e0  2**0
                  CONTENTS, READONLY
 16 .note.GNU-stack 00000000  0000000000000000  0000000000000000  00004506  2**0
                  CONTENTS, READONLY

Re: Unaligned accesses when loading modules

[Sami Tolvanen]

Hi Mikulas,

On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
>
> Hi
>
> On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
> a module is loaded. The warnings are caused by the fact that the
> .gnu.linkonce.this_module section is not aligned to the appropriate
> boundary. If I dump the module content with "objdump -h configs.ko", I get
> this. Note that the .gnu.linkonce.this_module has "File off 000042d2" and
> "Algn 2**4".
>
> On x86-64, the same misalignment can be seen, but it doesn't cause
> warnings because unaligned pointers are handled in hardware.
>
> This seems to be a bug in the linker, because when I compile an old kernel
> with a new linker, I also get the misalignment. Do you have an idea how to
> work around this bug?

Does explicitly specifying section alignment in the module linker
script fix this by any chance?

> kernel-6.12.9, binutils from Debian ports:
> [...]
> kernel 6.10, older binutils:

Which exact versions of binutils were used here? I don't see the
alignment issue with binutils 2.42 on either x86_64 or parisc64, so I
assume you're testing with something newer?

$ hppa64-linux-gnu-ld.bfd --version
GNU ld (GNU Binutils for Debian) 2.42.50.20240625

$ hppa64-linux-gnu-objdump -h configs.ko | grep -E '(format|this_module)'
configs.ko:     file format elf64-hppa-linux
 17 .gnu.linkonce.this_module 00000300  0000000000000000
0000000000000000  00005c50  2**4

Sami

Re: Unaligned accesses when loading modules

[Mikulas Patocka]

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]



On Tue, 14 Jan 2025, Sami Tolvanen wrote:

> Hi Mikulas,
> 
> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> > Hi
> >
> > On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
> > a module is loaded. The warnings are caused by the fact that the
> > .gnu.linkonce.this_module section is not aligned to the appropriate
> > boundary. If I dump the module content with "objdump -h configs.ko", I get
> > this. Note that the .gnu.linkonce.this_module has "File off 000042d2" and
> > "Algn 2**4".
> >
> > On x86-64, the same misalignment can be seen, but it doesn't cause
> > warnings because unaligned pointers are handled in hardware.
> >
> > This seems to be a bug in the linker, because when I compile an old kernel
> > with a new linker, I also get the misalignment. Do you have an idea how to
> > work around this bug?
> 
> Does explicitly specifying section alignment in the module linker
> script fix this by any chance?
> 
> > kernel-6.12.9, binutils from Debian ports:
> > [...]
> > kernel 6.10, older binutils:
> 
> Which exact versions of binutils were used here? I don't see the
> alignment issue with binutils 2.42 on either x86_64 or parisc64, so I
> assume you're testing with something newer?
> 
> $ hppa64-linux-gnu-ld.bfd --version
> GNU ld (GNU Binutils for Debian) 2.42.50.20240625
> 
> $ hppa64-linux-gnu-objdump -h configs.ko | grep -E '(format|this_module)'
> configs.ko:     file format elf64-hppa-linux
>  17 .gnu.linkonce.this_module 00000300  0000000000000000
> 0000000000000000  00005c50  2**4
> 
> Sami

Hi

I use version "GNU ld (GNU Binutils for Debian) 2.43.50.20250108".

It was broken in the commit 1f1b5e506bf0d9bffef8525eb9bee19646713eb6 in 
the binutils-gdb git and partially fixed in the commit 
d41df13ab36b224a622c0bdf28a96a0dee79db77 - the section is still not 
aligned at their specified boundary (16), but at least it is aligned on 8 
bytes, which avoids the warnings.

With binutils from git, I no longer see warnings when loading modules, but 
there are warnings in modpost when compiling the kernel:

2025-01-15T17:09:29.408347+01:00 phoebe kernel: handle_unaligned: 2165 callbacks suppressed
2025-01-15T17:09:29.408433+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bd5 at ip 0x015d03 (iir 0xf381086)
2025-01-15T17:09:29.602490+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bd1 at ip 0x015d07 (iir 0xf301088)
2025-01-15T17:09:29.700610+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096be9 at ip 0x015d0b (iir 0x4b3c0040)
2025-01-15T17:09:29.700653+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bdd at ip 0x015d0f (iir 0x4b240028)
2025-01-15T17:09:29.897081+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bd9 at ip 0x015d13 (iir 0x4b270020)

The affected instructions are in the function do_pci_entry:
   15d00:       0f 38 10 86     ldw c(r25),r6
   15d04:       0f 30 10 88     ldw 8(r25),r8
   15d08:       4b 3c 00 40     ldw 20(r25),ret0
   15d0c:       4b 24 00 28     ldw 14(r25),r4
   15d10:       4b 27 00 20     ldw 10(r25),r7
   15d14:       0f 28 10 89     ldw 4(r25),r9
   15d18:       82 93 20 e0     cmpb,= r19,r20,15d90 <do_pci_entry+0xcc>
   15d1c:       0f 20 10 8a     ldw 0(r25),r10
they happen in the expansion of the macro DEF_FIELD.

Mikulas

Re: Unaligned accesses when loading modules

[Jan Beulich]

On 15.01.2025 19:02, Mikulas Patocka wrote:
> On Tue, 14 Jan 2025, Sami Tolvanen wrote:
>> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
>>> On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
>>> a module is loaded. The warnings are caused by the fact that the
>>> .gnu.linkonce.this_module section is not aligned to the appropriate
>>> boundary. If I dump the module content with "objdump -h configs.ko", I get
>>> this. Note that the .gnu.linkonce.this_module has "File off 000042d2" and
>>> "Algn 2**4".
>>>
>>> On x86-64, the same misalignment can be seen, but it doesn't cause
>>> warnings because unaligned pointers are handled in hardware.
>>>
>>> This seems to be a bug in the linker, because when I compile an old kernel
>>> with a new linker, I also get the misalignment. Do you have an idea how to
>>> work around this bug?
>>
>> Does explicitly specifying section alignment in the module linker
>> script fix this by any chance?
>>
>>> kernel-6.12.9, binutils from Debian ports:
>>> [...]
>>> kernel 6.10, older binutils:
>>
>> Which exact versions of binutils were used here? I don't see the
>> alignment issue with binutils 2.42 on either x86_64 or parisc64, so I
>> assume you're testing with something newer?
>>
>> $ hppa64-linux-gnu-ld.bfd --version
>> GNU ld (GNU Binutils for Debian) 2.42.50.20240625
>>
>> $ hppa64-linux-gnu-objdump -h configs.ko | grep -E '(format|this_module)'
>> configs.ko:     file format elf64-hppa-linux
>>  17 .gnu.linkonce.this_module 00000300  0000000000000000
>> 0000000000000000  00005c50  2**4
>>
>> Sami
> 
> Hi
> 
> I use version "GNU ld (GNU Binutils for Debian) 2.43.50.20250108".
> 
> It was broken in the commit 1f1b5e506bf0d9bffef8525eb9bee19646713eb6 in 
> the binutils-gdb git and partially fixed in the commit 
> d41df13ab36b224a622c0bdf28a96a0dee79db77 - the section is still not 
> aligned at their specified boundary (16), but at least it is aligned on 8 
> bytes, which avoids the warnings.

When you say "broken", can you please explain what it is that is _broken_?
Things have changed, yes, but the produced ELF is - afaict - still within
spec. The "partial fix" as you call it wasn't really a fix, but a band-aid
for some broken consumers of ELF. Plus modpost, being one such example,
was supposedly corrected already (Linux commit 8fe1a63d3d99). Said "partial
fix" was also confirmed to help modpost [1] - are you saying that wasn't
quite true?

Jan

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=32435

> With binutils from git, I no longer see warnings when loading modules, but 
> there are warnings in modpost when compiling the kernel:
> 
> 2025-01-15T17:09:29.408347+01:00 phoebe kernel: handle_unaligned: 2165 callbacks suppressed
> 2025-01-15T17:09:29.408433+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bd5 at ip 0x015d03 (iir 0xf381086)
> 2025-01-15T17:09:29.602490+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bd1 at ip 0x015d07 (iir 0xf301088)
> 2025-01-15T17:09:29.700610+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096be9 at ip 0x015d0b (iir 0x4b3c0040)
> 2025-01-15T17:09:29.700653+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bdd at ip 0x015d0f (iir 0x4b240028)
> 2025-01-15T17:09:29.897081+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bd9 at ip 0x015d13 (iir 0x4b270020)
> 
> The affected instructions are in the function do_pci_entry:
>    15d00:       0f 38 10 86     ldw c(r25),r6
>    15d04:       0f 30 10 88     ldw 8(r25),r8
>    15d08:       4b 3c 00 40     ldw 20(r25),ret0
>    15d0c:       4b 24 00 28     ldw 14(r25),r4
>    15d10:       4b 27 00 20     ldw 10(r25),r7
>    15d14:       0f 28 10 89     ldw 4(r25),r9
>    15d18:       82 93 20 e0     cmpb,= r19,r20,15d90 <do_pci_entry+0xcc>
>    15d1c:       0f 20 10 8a     ldw 0(r25),r10
> they happen in the expansion of the macro DEF_FIELD.
> 
> Mikulas

Re: Unaligned accesses when loading modules

[Mikulas Patocka]

[-- Attachment #1: Type: text/plain, Size: 3289 bytes --]



On Thu, 16 Jan 2025, Jan Beulich wrote:

> On 15.01.2025 19:02, Mikulas Patocka wrote:
> > On Tue, 14 Jan 2025, Sami Tolvanen wrote:
> >> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
> >>> On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
> >>> a module is loaded. The warnings are caused by the fact that the
> >>> .gnu.linkonce.this_module section is not aligned to the appropriate
> >>> boundary. If I dump the module content with "objdump -h configs.ko", I get
> >>> this. Note that the .gnu.linkonce.this_module has "File off 000042d2" and
> >>> "Algn 2**4".
> >>>
> >>> On x86-64, the same misalignment can be seen, but it doesn't cause
> >>> warnings because unaligned pointers are handled in hardware.
> >>>
> >>> This seems to be a bug in the linker, because when I compile an old kernel
> >>> with a new linker, I also get the misalignment. Do you have an idea how to
> >>> work around this bug?
> >>
> >> Does explicitly specifying section alignment in the module linker
> >> script fix this by any chance?
> >>
> >>> kernel-6.12.9, binutils from Debian ports:
> >>> [...]
> >>> kernel 6.10, older binutils:
> >>
> >> Which exact versions of binutils were used here? I don't see the
> >> alignment issue with binutils 2.42 on either x86_64 or parisc64, so I
> >> assume you're testing with something newer?
> >>
> >> $ hppa64-linux-gnu-ld.bfd --version
> >> GNU ld (GNU Binutils for Debian) 2.42.50.20240625
> >>
> >> $ hppa64-linux-gnu-objdump -h configs.ko | grep -E '(format|this_module)'
> >> configs.ko:     file format elf64-hppa-linux
> >>  17 .gnu.linkonce.this_module 00000300  0000000000000000
> >> 0000000000000000  00005c50  2**4
> >>
> >> Sami
> > 
> > Hi
> > 
> > I use version "GNU ld (GNU Binutils for Debian) 2.43.50.20250108".
> > 
> > It was broken in the commit 1f1b5e506bf0d9bffef8525eb9bee19646713eb6 in 
> > the binutils-gdb git and partially fixed in the commit 
> > d41df13ab36b224a622c0bdf28a96a0dee79db77 - the section is still not 
> > aligned at their specified boundary (16), but at least it is aligned on 8 
> > bytes, which avoids the warnings.
> 
> When you say "broken", can you please explain what it is that is _broken_?
> Things have changed, yes, but the produced ELF is - afaict - still within
> spec. The "partial fix" as you call it wasn't really a fix, but a band-aid
> for some broken consumers of ELF. Plus modpost, being one such example,
> was supposedly corrected already (Linux commit 8fe1a63d3d99). Said "partial
> fix" was also confirmed to help modpost [1] - are you saying that wasn't
> quite true?
> 
> Jan

By "broken" I mean that the file offset is not aligned to the section's 
alignment.

By "partial fix" I mean that the file offset is aligned to 8 bytes, but 
the section's alignment is 16.

When Linux loads a module, it takes the .gnu.linkonce.this_module section 
from the module file and points a pointer to "struct module *" to it (see 
"info->mod = (void *)info->hdr + info->sechdrs[info->index.mod].sh_offset;").
So, if the section is misaligned, you get warnings about kernel accesses 
to unaligned memory.

That commit 8fe1a63d3d99 should have been ported to the stable kernels (I 
used the kernel 6.12.9 which lacks it), I'll post it there.

Mikulas

Re: Unaligned accesses when loading modules

[Jan Beulich]

On 16.01.2025 16:29, Mikulas Patocka wrote:
> 
> 
> On Thu, 16 Jan 2025, Jan Beulich wrote:
> 
>> On 15.01.2025 19:02, Mikulas Patocka wrote:
>>> On Tue, 14 Jan 2025, Sami Tolvanen wrote:
>>>> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
>>>>> On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
>>>>> a module is loaded. The warnings are caused by the fact that the
>>>>> .gnu.linkonce.this_module section is not aligned to the appropriate
>>>>> boundary. If I dump the module content with "objdump -h configs.ko", I get
>>>>> this. Note that the .gnu.linkonce.this_module has "File off 000042d2" and
>>>>> "Algn 2**4".
>>>>>
>>>>> On x86-64, the same misalignment can be seen, but it doesn't cause
>>>>> warnings because unaligned pointers are handled in hardware.
>>>>>
>>>>> This seems to be a bug in the linker, because when I compile an old kernel
>>>>> with a new linker, I also get the misalignment. Do you have an idea how to
>>>>> work around this bug?
>>>>
>>>> Does explicitly specifying section alignment in the module linker
>>>> script fix this by any chance?
>>>>
>>>>> kernel-6.12.9, binutils from Debian ports:
>>>>> [...]
>>>>> kernel 6.10, older binutils:
>>>>
>>>> Which exact versions of binutils were used here? I don't see the
>>>> alignment issue with binutils 2.42 on either x86_64 or parisc64, so I
>>>> assume you're testing with something newer?
>>>>
>>>> $ hppa64-linux-gnu-ld.bfd --version
>>>> GNU ld (GNU Binutils for Debian) 2.42.50.20240625
>>>>
>>>> $ hppa64-linux-gnu-objdump -h configs.ko | grep -E '(format|this_module)'
>>>> configs.ko:     file format elf64-hppa-linux
>>>>  17 .gnu.linkonce.this_module 00000300  0000000000000000
>>>> 0000000000000000  00005c50  2**4
>>>>
>>>> Sami
>>>
>>> Hi
>>>
>>> I use version "GNU ld (GNU Binutils for Debian) 2.43.50.20250108".
>>>
>>> It was broken in the commit 1f1b5e506bf0d9bffef8525eb9bee19646713eb6 in 
>>> the binutils-gdb git and partially fixed in the commit 
>>> d41df13ab36b224a622c0bdf28a96a0dee79db77 - the section is still not 
>>> aligned at their specified boundary (16), but at least it is aligned on 8 
>>> bytes, which avoids the warnings.
>>
>> When you say "broken", can you please explain what it is that is _broken_?
>> Things have changed, yes, but the produced ELF is - afaict - still within
>> spec. The "partial fix" as you call it wasn't really a fix, but a band-aid
>> for some broken consumers of ELF. Plus modpost, being one such example,
>> was supposedly corrected already (Linux commit 8fe1a63d3d99). Said "partial
>> fix" was also confirmed to help modpost [1] - are you saying that wasn't
>> quite true?
> 
> By "broken" I mean that the file offset is not aligned to the section's 
> alignment.

Except that this isn't broken at all. The section's alignment has no meaning
for the file offset (in ordinary object files that is; things are different
for executables); it solely affects the eventual virtual address assignment
by the linker.

> By "partial fix" I mean that the file offset is aligned to 8 bytes, but 
> the section's alignment is 16.
> 
> When Linux loads a module, it takes the .gnu.linkonce.this_module section 
> from the module file and points a pointer to "struct module *" to it (see 
> "info->mod = (void *)info->hdr + info->sechdrs[info->index.mod].sh_offset;").
> So, if the section is misaligned, you get warnings about kernel accesses 
> to unaligned memory.

Right, but that's a problem with the code you quote. The mere use of a
cast plus the assignment of a void * pointer to one requiring better
alignment is already indicative of possible problems.

Jan

Re: Unaligned accesses when loading modules

[Maciej W. Rozycki]

On Thu, 16 Jan 2025, Jan Beulich wrote:

> >> When you say "broken", can you please explain what it is that is _broken_?
> >> Things have changed, yes, but the produced ELF is - afaict - still within
> >> spec. The "partial fix" as you call it wasn't really a fix, but a band-aid
> >> for some broken consumers of ELF. Plus modpost, being one such example,
> >> was supposedly corrected already (Linux commit 8fe1a63d3d99). Said "partial
> >> fix" was also confirmed to help modpost [1] - are you saying that wasn't
> >> quite true?
> > 
> > By "broken" I mean that the file offset is not aligned to the section's 
> > alignment.
> 
> Except that this isn't broken at all. The section's alignment has no meaning
> for the file offset (in ordinary object files that is; things are different
> for executables); it solely affects the eventual virtual address assignment
> by the linker.

 FAOD for ET_EXEC/ET_DYN files section alignment has no relevance either 
(and sections are not required to be present there in the first place) and 
any tools are supposed to cope with it where applicable, but what matters 
is segment alignment and that continues to be respected.

 NB there is a way to produce optimal code according to the architecture's 
capabilities for unaligned accesses where required, by using the "packed" 
type/variable attribute.  I'm sure there are usage examples already there 
in the kernel.

  Maciej