[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXHZ8QOU23+c5CCkEAo2sq4acOfDOsyh-SuKfHoJregQ5g@mail.gmail.com>
Date: Mon, 27 Jan 2025 23:15:18 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org, x86@...nel.org,
Ingo Molnar <mingo@...nel.org>, Tom Lendacky <thomas.lendacky@....com>,
Nathan Chancellor <nathan@...nel.org>
Subject: Re: [RFC PATCH 2/2] x86/sev: Disable jump tables in SEV startup code
On Mon, 27 Jan 2025 at 18:10, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Mon, 27 Jan 2025 at 03:43, Ard Biesheuvel <ardb+git@...gle.com> wrote:
> >
> > +# jump tables are emitted using absolute references in non-PIC code
> > +# so they cannot be used in the early SEV startup code
> > +CFLAGS_core.o += -fno-jump-tables
>
> I can confirm that this looks like it fixes the problem for my
> particular config.
>
Great.
> Is the SEV code the only thing that needs this? And on the other hand,
> isn't it just a _part_ of core.c that needs this? Maybe the "_head"
> parts should be in a separate file?
>
> I'm looking at (for example) arch/x86/mm/mem_encrypt_identity.c and
> arch/x86/kernel/head64.c, and it looks like it really should have that
> -fno-jump-tables thing too.
>
> It just randomly may not have any switch tables or other things that
> makes the compiler generate that code pattern.
>
Yes. This is essentially whack-a-mole. And note that placing functions
in .head.text is a manual process, and so there may be other code that
is reachable via early code paths that remain unchecked.
The right way to go about this would be to duplicate what I did for
arm64 in arch/arm64/kernel/pi/, i.e., to create a special set of
source files that can be called into, but cannot call out to other
code unless it is part of the same pi/ corpus. These files are built
with an entirely different set of compiler options, -fPIC being one of
the notable ones. The resulting objects are checked for absolute
relocations in a similar fashion, and are therefore guaranteed to be
truly position independent (hence the 'pi') without any need for
runtime fixups. (Note that these objects are still linked into vmlinux
as usual, but due to the symbol name prefixes added using objcopy,
they are part of an isolated namespace)
The use case is also quite similar to the x86 one, as a matter of
fact: the initial mapping of the arm64 kernel is also 1:1, and some
non-trivial work is needed before the kernel's virtual mapping can be
created, and doing all of that in C was becoming intractable.
If this seems like a sensible approach for x86 as well, I can do some
exploration into the feasibility (keeping in mind that a lot of this
code is already being shared with the decompressor and the EFI stub
too, so it might take some effort to untangle)
Powered by blists - more mailing lists