lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0144332b-be9c-2f6d-81bc-a18f13990d65@redhat.com>
Date: Thu, 16 Jan 2025 16:29:51 +0100 (CET)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Jan Beulich <jbeulich@...e.com>
cc: Luis Chamberlain <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>, 
    Daniel Gomez <da.gomez@...sung.com>, 
    "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>, 
    Helge Deller <deller@....de>, linux-modules@...r.kernel.org, 
    linux-kernel@...r.kernel.org, linux-parisc@...r.kernel.org, 
    Sami Tolvanen <samitolvanen@...gle.com>
Subject: Re: Unaligned accesses when loading modules



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@...hat.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ