linux-kernel - Re: [RFT PATCH v3 00/21] x86: strict separation of startup code

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aCQ2L3L2DQX80blY@gmail.com>
Date: Wed, 14 May 2025 08:20:31 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
	linux-efi@...r.kernel.org, x86@...nel.org,
	Ard Biesheuvel <ardb@...nel.org>,
	Dionna Amalie Glaze <dionnaglaze@...gle.com>,
	Kevin Loughlin <kevinloughlin@...gle.com>,
	Tom Lendacky <thomas.lendacky@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFT PATCH v3 00/21] x86: strict separation of startup code


* Borislav Petkov <bp@...en8.de> wrote:

> > Note that two of those fixes were from Ard who is working on 
> > further robustifying the startup code - a much needed change.
> 
> Please do explain why is it much needed?

See Ard's excellent description:

    https://lore.kernel.org/r/CAMj1kXEzKEuePEiHB+HxvfQbFz0sTiHdn4B++zVBJ2mhkPkQ4Q@mail.gmail.com

    This C startup code has been expanding, and in particular, the SEV-SNP
    startup code has been expanding over the past couple of years, and
    grown many of these warts, where the C code needs to use special
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
    annotations or helpers to access global objects.

    Google uses Clang internally, and as expected, it does not behave
    quite like GCC in this regard either. The result is that the SEV-SNP
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    boot tended to break in cryptic ways with Clang built kernels, due to
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    absolute references in the startup code that runs before those
    absolute references are mapped.

    I've done a preliminary pass upstream with RIP_REL_REF() and
    rip_rel_ptr() and the use of the .head.text section for startup code
    to ensure that we detect such issues at build time, and it has already
    resulted in a number of true positives where the code in question
    would have failed at boot time. At this point, I'm not aware of any
    issues caused by absolute references going undetected.

    However, Linus kindly indicated that the resulting diagnostics
    produced by the relocs tool do not meet his high standards, and so I
    proposed another approach, which I am implementing now (see cover
    letter for details). Note that this approach is also much more robust,
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    as annotating things as __head by hand to get it emitted into the
    section to which the diagnostics are applied is obviously not
    foolproof.

    Fixing the existing 5-level paging and kernel mapping code was rather
    straight-forward. However, splitting up the SEV-SNP code has been
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    rather challenging due to the way it was put together, i.e., as a
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    single source file used everywhere, and to which additional
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    functionality has been added piecemeal (i.e., the SVSM support).
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I've highlighted all the robustness problems and design flaws of the 
existing SEV* startup code...

> Really? Much needed huh?

Your failure to follow and understand this series is not an excuse for 
the flippant and condescending tone you are using in your replies ...

Ard is being very generous in his responses, and I'll defer to him as 
to the timing of this series: v6.17 is perfectly fine too.

Thanks,

	Ingo