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: <ea468b86-abb7-bb2b-1e0a-4c8959d23f1c@kernel.org>
Date:   Mon, 24 Oct 2022 20:24:50 +0200
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Masahiro Yamada <masahiroy@...nel.org>,
        linux-kbuild@...r.kernel.org
Cc:     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>,
        Michael Matz <matz@...e.de>, 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

Hi,

following an IRC discussion with many parties...

On 24. 09. 22, 20:19, Masahiro Yamada wrote:
> The objects placed at the head of vmlinux need special treatments:
> 
>   - arch/$(SRCARCH)/Makefile adds them to head-y in order to place
>     them before other archives in the linker command line.
> 
>   - arch/$(SRCARCH)/kernel/Makefile adds them to extra-y instead of
>     obj-y to avoid them going into built-in.a.
> 
> This commit gets rid of the latter.
> 
> Create vmlinux.a to collect all the objects that are unconditionally
> linked to vmlinux. The objects listed in head-y are moved to the head
> of vmlinux.a by using 'ar m'.
> 
> With this, arch/$(SRCARCH)/kernel/Makefile can consistently use obj-y
> for builtin objects.
> 
> There is no *.o that is directly linked to vmlinux. Drop unneeded code
> in scripts/clang-tools/gen_compile_commands.py.
> 
> $(AR) mPi needs 'T' to workaround the llvm-ar bug. The fix was suggested
> by Nathan Chancellor [1].
> 
> [1]: https://lore.kernel.org/llvm/YyjjT5gQ2hGMH0ni@dev-arch.thelio-3990X/
> 
> Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
> ---
...
> --- a/scripts/Makefile.vmlinux_o
> +++ b/scripts/Makefile.vmlinux_o
> @@ -18,7 +18,7 @@ quiet_cmd_gen_initcalls_lds = GEN     $@
>   	$(PERL) $(real-prereqs) > $@
>   
>   .tmp_initcalls.lds: $(srctree)/scripts/generate_initcall_order.pl \
> -		$(KBUILD_VMLINUX_OBJS) $(KBUILD_VMLINUX_LIBS) FORCE
> +		vmlinux.a $(KBUILD_VMLINUX_LIBS) FORCE

There is a slight problem with this. The kernel built with gcc-LTO does 
not boot. But as I understand it, it's not limited to gcc-LTO only.

On x86, startup_64() is supposed to be at offset >zero< of the image 
(see .Lrelocated()). It was ensured by putting head64.o to the beginning 
of vmlinux (by KBUILD_VMLINUX_OBJS on the LD command-line above). The 
patch above instead packs head64.o into vmlinux.a and then moves it 
using "ar -m" to the beginning (it's in 7/7 of the series IIRC).

The problem is that .o files listed on the LD command line explicitly 
are taken as spelled. But unpacking .a inside LD gives no guarantees on 
the order of packed objects. To quote: "that it happens to work 
sometimes is pure luck." (Correct me guys, if I misunderstood you.)

For x86, the most ideal fix seems to be to fix it in the linker script. 
By putting startup_64() to a different section and handle it in the ld 
script specially -- see the attachment. It should always have been put 
this way, the command line order is only a workaround. But this might 
need more fixes on other archs too -- I haven't take a look.

Ideas, comments? I'll send the attachment as a PATCH later (if there are 
no better suggestions).

thanks,
-- 
js
suse labs

View attachment "0001-head-fix.patch" of type "text/x-patch" (1731 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ