linux-kernel - Re: [PATCH v5 1/3] x86/sev: Add new dump_rmp parameter to snp_leak

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: <45528c22-9fe7-4f7d-97e9-1d58a0415b08@amd.com>
Date: Tue, 16 Sep 2025 08:58:42 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Borislav Petkov <bp@...en8.de>, Ashish Kalra <Ashish.Kalra@....com>
Cc: tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
 x86@...nel.org, hpa@...or.com, seanjc@...gle.com, pbonzini@...hat.com,
 herbert@...dor.apana.org.au, nikunj@....com, davem@...emloft.net,
 aik@....com, ardb@...nel.org, john.allen@....com, michael.roth@....com,
 Neeraj.Upadhyay@....com, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
 linux-crypto@...r.kernel.org
Subject: Re: [PATCH v5 1/3] x86/sev: Add new dump_rmp parameter to
 snp_leak_pages() API

On 9/16/25 08:12, Borislav Petkov wrote:
> On Mon, Sep 15, 2025 at 09:21:58PM +0000, Ashish Kalra wrote:
>> @@ -668,6 +673,7 @@ static inline int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 as
>>  	return -ENODEV;
>>  }
>>  static inline int rmp_make_shared(u64 pfn, enum pg_level level) { return -ENODEV; }
>> +static inline void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp) {}
>>  static inline void snp_leak_pages(u64 pfn, unsigned int npages) {}
> 
> I basically don't even have to build your patch to see that this can't build.
> See below.

Did the patch merge correctly? I can't see how it would fail since both
the original and new definitions are in separate parts of the #ifdef... It
should have failed even before given the way it was changed.

Maybe I'm missing something.

Thanks,
Tom

> 
> When your patch touches code behind different CONFIG_ items, you must make
> sure it builds with both settings of each CONFIG_ item.
> 
> In file included from arch/x86/boot/startup/gdt_idt.c:9:
> ./arch/x86/include/asm/sev.h:679:20: error: redefinition of ‘snp_leak_pages’
>   679 | static inline void snp_leak_pages(u64 pfn, unsigned int pages)
>       |                    ^~~~~~~~~~~~~~
> ./arch/x86/include/asm/sev.h:673:20: note: previous definition of ‘snp_leak_pages’ with type ‘void(u64,  unsigned int)’ {aka ‘void(long long unsigned int,  unsigned int)’}
>   673 | static inline void snp_leak_pages(u64 pfn, unsigned int npages) {}
>       |                    ^~~~~~~~~~~~~~
> make[4]: *** [scripts/Makefile.build:287: arch/x86/boot/startup/gdt_idt.o] Error 1
> make[3]: *** [scripts/Makefile.build:556: arch/x86/boot/startup] Error 2
> make[2]: *** [scripts/Makefile.build:556: arch/x86] Error 2
> make[2]: *** Waiting for unfinished jobs....
> In file included from drivers/iommu/amd/init.c:32:
> ./arch/x86/include/asm/sev.h:679:20: error: redefinition of ‘snp_leak_pages’
>   679 | static inline void snp_leak_pages(u64 pfn, unsigned int pages)
>       |                    ^~~~~~~~~~~~~~
> ./arch/x86/include/asm/sev.h:673:20: note: previous definition of ‘snp_leak_pages’ with type ‘void(u64,  unsigned int)’ {aka ‘void(long long unsigned int,  unsigned int)’}
>   673 | static inline void snp_leak_pages(u64 pfn, unsigned int npages) {}
>       |                    ^~~~~~~~~~~~~~
> make[5]: *** [scripts/Makefile.build:287: drivers/iommu/amd/init.o] Error 1
> make[4]: *** [scripts/Makefile.build:556: drivers/iommu/amd] Error 2
> make[4]: *** Waiting for unfinished jobs....
> make[3]: *** [scripts/Makefile.build:556: drivers/iommu] Error 2
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [scripts/Makefile.build:556: drivers] Error 2
> make[1]: *** [/mnt/kernel/kernel/linux/Makefile:2011: .] Error 2
> make: *** [Makefile:248: __sub-make] Error 2
>