linux-kernel - Re: [PATCH v3 6/7] kbuild: use obj-y instead extra-y for objects placed at the head

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]

Date:   Wed, 26 Oct 2022 17:09:49 +0000 (UTC)
From:   Michael Matz <matz@...e.de>
To:     Masahiro Yamada <masahiroy@...nel.org>
cc:     Jiri Slaby <jirislaby@...nel.org>, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Martin Liška <mliska@...e.cz>,
        Borislav Petkov <bpetkov@...e.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH v3 6/7] kbuild: use obj-y instead extra-y for objects
 placed at the head

Hello,

On Thu, 27 Oct 2022, Masahiro Yamada wrote:

> > To be precise: I know of no linker (outside LTO-like modes) that processes
> > archives in a different order than first-to-last-member (under
> > whole-archive), but that's not guaranteed anywhere.  So relying on
> > member-order within archives is always brittle.
> 
> The objects in an archive are linked first-to-last-member for a long time.
> This is the assumption which we have relied on for a long time.

Sure, that doesn't mean it's guaranteed, for this I'm just devils 
advocate.  As I said, it's the mode of operation of all currently existing 
linkers I know, so for the forseeable future you can continue to rely on 
it.  But as soon as LTO enters the picture that all breaks down, as you 
see here.

Consider how LTO works, the granularity of shuffling stuff around is the 
functions of all inputs, not the object files.  So, even if you say
  obj1.o obj2.o
on the link command line, and supposed there are two functions in each of 
obj1 and obj2, then it may just so happen that LTO partitions the program 
such that it ends up with partitions
  part1 : obj1:foo obj2:bar
  part2 : obj1:bar obj2:foo
now, suddenly there is no order between part1 and part2 anymore that 
would faithfully represent the original order between obj1 and obj2 
functions.  Of course the partitioning algorithm could be changed, but 
that would limit the effectiveness of LTO.

> We assume the initcall order is preserved.
> The call order within each of core_initcall, arch_initcall,
> device_initcall, etc.
> is the order of objects in built-in.a, in other words,
> the order they appear in Makefiles.

If you rely on relative order of these, then you will probably see 
interesting effects in LTO mode eventually.

> So, this is happening on (not-upstreamed-yet) GCC LTO only?

I don't know.  As any kind of whole-program transformations is in 
principle cross-file on per-function basis (that's the whole purpose) I 
would imagine that you can see these effects in all compilers, if you try 
hard enough.

> > There are only two ways of guaranteeing an ordering: put non-LTO-.o files
> > at certain places of the link command, or, better, use a linker script to
> > specify an order.
> 
> The objects directly given in the command line are linked in the same order,
> even under LTO mode. Is this what you mean?

If they don't contain LTO code then yes, they are linked 
in exactly the given order.  If they do, they become part of the LTO blob 
whose ordering isn't precisely influenced by cmdline order.

> Any documentation about that?

I think so, but I can't point my finger to anything.  Several parts of the 
toolchain rely on that (so the kernel is not alone), but those are either 
carefully avoiding LTO or using other ordering means like linker script to 
achieve what they need.

Ciao,
Michael.