linux-kernel - Re: [GIT PULL] x86/boot enhancements for v6.14

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: <CAHk-=wj7k9nvJn6cpa3-5Ciwn2RGyE605BMkjWE4MqnvC9E92A@mail.gmail.com>
Date: Sun, 26 Jan 2025 19:18:51 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...nel.org>, Ard Biesheuvel <ardb@...nel.org>
Cc: linux-kernel@...r.kernel.org, "the arch/x86 maintainers" <x86@...nel.org>, 
	David Woodhouse <dwmw2@...radead.org>, Peter Zijlstra <peterz@...radead.org>, 
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT PULL] x86/boot enhancements for v6.14

On Tue, 21 Jan 2025 at 13:29, Ingo Molnar <mingo@...nel.org> wrote:
>
> - A series to remove the last remaining absolute symbol references from
>   .head.text, and enforce this at build time, by Ard Biesheuvel:
> [...]
>  - Which build-time enforcement uncovered a handful of bugs of essentially
>    non-working code, and a wrokaround for a toolchain bug, fixed by
>    Ard Biesheuvel as well:
>
>       - Fix spurious undefined reference when CONFIG_X86_5LEVEL=n, on GCC-12
>       - Disable UBSAN on SEV code that may execute very early
>       - Disable ftrace branch profiling in SEV startup code

Bah. I only noticed this today, because I was on the road part of the
week and didn't do my usual "build with clang".

But this is broken with my normal clang config, and I get a very
unhelpful error message:

    Absolute reference to symbol '.rodata' not permitted in .head.text

and I have no idea why, or where it comes from.  And that error
message doesn't specify enough information for me to even *guess* at
what's going on.

And bisecting it obviously just points at faf0ed487415 ("x86/boot:
Reject absolute references in .head.text"), since it's just a random
new check for an old issue.

New random rule, with new random error as a result, and totally opaque
to anybody else than Ard.

Useless crap, in other words.

Why isn't the fix a revert? Because that error message is really bad.
It needs to tell me where things went wrong, not just a "You're effed.
Ha! Ha!".

And to add insult to injury, all of this is done in-place on the
vmlinux file, so when it all fails, make does

    make[2]: *** Deleting file 'vmlinux'

and doesn't even leave behind anything to look at.

So I really think this was all horribly badly done.

Anyway, not know what the right thing to do is, I hacked up the
makefiles to squirrel off a copy of the vmlinux file, and did

        objdump --no-addresses --no-show-raw-insn \
                -j .head.text --disassemble \
                -rR ORIGINAL  | less -S

and sure enough, it shows things like this:

  <snp_cpuid>:
        push   %rbp
        push   %r15
        push   %r14
        push   %rbx
        sub    $0x18,%rsp
        lea    0x5ac8fb(%rip),%r8        # <cpuid_table_copy>
                        R_X86_64_PC32   .rodata+0x4f1758
        mov    (%r8),%eax
        test   %eax,%eax
    ..
        lea    0x5ac841(%rip),%rax        # <cpuid_std_range_max>
                        R_X86_64_PC32   .rodata+0x4f174c
    ..
        jmp    *-0x7dfffe90(,%r9,8)
                        R_X86_64_32S    .rodata+0x170
    ..

and

  <snp_init>:
        push   %rbp
        push   %r15
        push   %r14
        push   %r12
    ..
        mov    %rax,0x5ac3bb(%rip)        # <secrets_pa>
                        R_X86_64_PC32   .rodata+0x4f173c
        mov    0x18(%r15),%rsi
        test   %rsi,%rsi
    ..

and

  <pvalidate_4k_page>:
        push   %rbx
        sub    $0x60,%rsp
        lea    0x5ac0c4(%rip),%rax        # <snp_vmpl>
   ..
        test   $0x4,%cl
        jne    <pvalidate_4k_page+0xad>
        lea    0x5ac068(%rip),%rax        # <boot_svsm_caa>
                        R_X86_64_PC32   .rodata+0x4f1744
        mov    (%rax),%rax
        jmp    <pvalidate_4k_page+0xb8>
    ..

so those relocs to rodata most definitely exist.

Anyway, that check needs to either

 (a) die a painful death very quickly

 (b) be made to actually print out useful information of WHERE the
relocation comes from and WHERE it points to

because the current implementation of that check is not acceptable.

The next time I have to play makefile games and then do objdump by
hand to figure out what the %^$% the build is complaining about, I'm
just reverting it outright and not writing this long explanation of
the problem.

                  Linus