linux-kernel - Re: [PATCH] platform/x86/amd/hsmp: mark hsmp_msg_desc_table[] as maybe

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: <5bee1158-537f-4fb2-bde3-e86b5dce3fee@redhat.com>
Date: Wed, 30 Oct 2024 15:16:53 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Arnd Bergmann <arnd@...nel.org>, Suma Hegde <suma.hegde@....com>
Cc: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@....com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org, Arnd Bergmann <arnd@...db.de>,
 Carlos Bilbao <carlos.bilbao.osdev@...il.com>, "H. Peter Anvin"
 <hpa@...or.com>, Randy Dunlap <rdunlap@...radead.org>,
 Bjorn Helgaas <bhelgaas@...gle.com>, platform-driver-x86@...r.kernel.org,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] platform/x86/amd/hsmp: mark hsmp_msg_desc_table[] as
 maybe_unused

Hi,

On 29-Oct-24 1:55 PM, Ilpo Järvinen wrote:
> On Mon, 28 Oct 2024, Arnd Bergmann wrote:
> 
> + Hans
> 
>> From: Arnd Bergmann <arnd@...db.de>
>>
>> After the file got split, there are now W=1 warnings for users that
>> include it without referencing hsmp_msg_desc_table:
>>
>> In file included from arch/x86/include/asm/amd_hsmp.h:6,
>>                  from drivers/platform/x86/amd/hsmp/plat.c:12:
>> arch/x86/include/uapi/asm/amd_hsmp.h:91:35: error: 'hsmp_msg_desc_table' defined but not used [-Werror=unused-const-variable=]
>>    91 | static const struct hsmp_msg_desc hsmp_msg_desc_table[] = {
>>       |                                   ^~~~~~~~~~~~~~~~~~~
>>
>> Mark it as __attribute__((maybe_unused)) to shut up the warning but
>> keep it in the file in case it is used from userland. The __maybe_unused
>> shorthand unfurtunately isn't available in userspace, so this has to
> 
> unfortunately
> 
>> be the long form.
>>
>> Fixes: e47c018a0ee6 ("platform/x86/amd/hsmp: Move platform device specific code to plat.c")
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>> ---
>> Ideally this array wouldn't be part of the UAPI at all, since it is
>> not really a interface, but it's hard to know what part  of the header
>> is actually used outside of the kernel.
> 
> Sadly this slipped through during review even if it was brought up by 
> somebody back then. The (rather weak) reasoning for having it as a part of 
> UAPI was seemingly accepted uncontested :-(.
> 
>> ---
>>  arch/x86/include/uapi/asm/amd_hsmp.h | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/include/uapi/asm/amd_hsmp.h b/arch/x86/include/uapi/asm/amd_hsmp.h
>> index e5d182c7373c..4a7cace06204 100644
>> --- a/arch/x86/include/uapi/asm/amd_hsmp.h
>> +++ b/arch/x86/include/uapi/asm/amd_hsmp.h
>> @@ -88,7 +88,8 @@ struct hsmp_msg_desc {
>>   *
>>   * Not supported messages would return -ENOMSG.
>>   */
>> -static const struct hsmp_msg_desc hsmp_msg_desc_table[] = {
>> +static const struct hsmp_msg_desc hsmp_msg_desc_table[]
>> +				__attribute__((unused)) = {
> 
> It seems that the main goal why it was put into UAPI was "to give the user 
> some reference about proper num_args and response_size for each message":
> 
> https://lore.kernel.org/all/CAPhsuW5V0BJT+YSwv1U=hRG0k9zBWXeRd=E1n4U5hvcnwEV3mQ@mail.gmail.com/
> 
> Are we actually expecting userspace to benefit from this in C form?
> Suma? Hans?

I can see how having this available in the uapi header as documentation
of sorts is somewhat useful.

OTOH I do agree that this array should probably not be used by userspace.

And there is only 1 way to find out if it is actually used (which I do not
expect) and that is to just drop it and find out (and to be willing to
revert the change if it breaks things).

So we can either move the array in its entirety to the c-code consuming it,
which I think would be best; or we can go with Arnd's patch + add

#ifdef __KERNEL__ 

around the array so that it is there for people reading the header, but
it is no longer exposed as uapi.

Regards,

Hans

> 
>>  	/* RESERVED */
>>  	{0, 0, HSMP_RSVD},
> 
>