[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac044150-ffb1-09b5-1f36-fdd6e259ba59@amd.com>
Date: Tue, 9 Apr 2024 12:44:13 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, linux-coco@...ts.linux.dev,
svsm-devel@...onut-svsm.dev, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Dan Williams <dan.j.williams@...el.com>, Michael Roth
<michael.roth@....com>, Ashish Kalra <ashish.kalra@....com>
Subject: Re: [PATCH v3 01/14] x86/sev: Rename snp_init() in the
boot/compressed/sev.c file
On 4/9/24 12:09, Borislav Petkov wrote:
> On Mon, Mar 25, 2024 at 05:26:20PM -0500, Tom Lendacky wrote:
>> The snp_init() in boot/compressed/sev.c is local to that file and is not
>> called from outside of the file. Change the name so that it is not tied
>> to the function definition in arch/x86/include/asm/sev.h.
>
> That part I don't understand: I can rename the function without making
> it static and it builds fine, so where is it "tied" to the function
> definition in kernel proper?
When it's not static and has the name snp_init(), then it has to match
the definition in arch/x86/include/asm/sev.h, which is really intended
for the snp_init() in arch/x86/kernel/sev.c when called from
arch/x86/mm/mem_encrypt_identity.c.
So, yes, changing the name would be enough except then it remains not a
static and you can get a compiler warning about not having a prototype
for it if the -Wmissing-prototypes option is ever applied to that file
(I don't believe it is today because it is in the decompressor code, but
that can change). And since nothing calls the snp_init() in
arch/x86/boot/compressed/sev.c from outside of that file, making it
static was appropriate.
Thanks,
Tom
>
> Don't get me wrong - leaking kernel proper symbols into the decompressor
> has been a pet peeve of mine for a while now but this is not the case
> here, is it?
>
> And yes, the patch is fine - I'm just asking...
>
> Thx.
>
Powered by blists - more mailing lists