linux-kernel - Re: [RFT PATCH v2 05/23] x86/sev: Move instruction decoder into separate source file

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: <CAMj1kXEpO3bip+Zyi9x4WN_=qy+oBQ+PpJRw-Je=roQcRt3KsA@mail.gmail.com>
Date: Wed, 7 May 2025 13:49:19 +0200
From: Ard Biesheuvel <ardb@...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, Ingo Molnar <mingo@...nel.org>, 
	Dionna Amalie Glaze <dionnaglaze@...gle.com>, Kevin Loughlin <kevinloughlin@...gle.com>, 
	Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [RFT PATCH v2 05/23] x86/sev: Move instruction decoder into
 separate source file

On Wed, 7 May 2025 at 11:58, Borislav Petkov <bp@...en8.de> wrote:
>
> On Sun, May 04, 2025 at 11:52:35AM +0200, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@...nel.org>
> >
> > As a first step towards disentangling the SEV #VC handling code -which
> > is shared between the decompressor and the core kernel- from the SEV
> > startup code, move the decompressor's copy of the instruction decoder
> > into a separate source file.
>
> Why?
>
> I'm still unclear why that happens.
>
> I'd like to read some blurb in those commit messages which explains the big
> picture: the insn decoder bits are going to be in the bla mapping because...
> , and because... and this is wonderful because ...
>

Sure, I can add some more prose. I'll add something along the lines of

"Some of the SEV code that is shared between the decompressor and the
kernel proper runs very early in the latter, and therefore needs to be
built in a special way. This does not apply to all of that shared
code, though - some is used both by the decompressor, and by the
kernel proper but at a much later stage. That code can be built as
ordinary, position dependent code with instrumentations enabled etc
etc.

The #VC handling machinery and the associated instruction decoder are
conceptually separate from the SEV initialization code, and are never
used on the early startup path in the core kernel. So start separating
it from the SEV startup code, by moving the decompressor's copy of the
instruction decoder to a separate source file. In a subsequent patch,
the shared #VC handling code will be moved into a separate shared
source file, which will be included here too and no longer into sev.c.
That way, it no longer gets included into the early SEV startup code,
and can be built in the ordinary way."

Does that help?