linux-kernel - Re: Unaligned accesses when loading modules

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2501170148420.27432@angie.orcam.me.uk>
Date: Fri, 17 Jan 2025 02:00:50 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Jan Beulich <jbeulich@...e.com>
cc: Mikulas Patocka <mpatocka@...hat.com>, 
    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:

> >> 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