linux-kernel - Re: [PATCH v2] platform/x86/amd: Don't allow HSMP to be loaded on non-server hardware

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]

Date: Thu, 18 Apr 2024 20:38:43 -0500
From: Mario Limonciello <superm1@...il.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Hans de Goede <hdegoede@...hat.com>,
 Naveen Krishna Chatradhi <naveenkrishna.chatradhi@....com>,
 Carlos Bilbao <carlos.bilbao@....com>,
 "open list:AMD HSMP DRIVER" <platform-driver-x86@...r.kernel.org>,
 open list <linux-kernel@...r.kernel.org>,
 Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH v2] platform/x86/amd: Don't allow HSMP to be loaded on
 non-server hardware



On 4/18/24 08:51, Ilpo Järvinen wrote:
> On Thu, 18 Apr 2024, Mario Limonciello wrote:
>> On 4/18/24 04:04, Hans de Goede wrote:
>>> On 4/16/24 8:20 PM, Mario Limonciello wrote:
>>>> From: Mario Limonciello <mario.limonciello@....com>
>>>>
>>>> If the HSMP driver is compiled into the kernel or a module manually loaded
>>>> on client hardware it can cause problems with the functionality of the PMC
>>>> module since it probes a mailbox with a different definition on servers.
>>>>
>>>> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2414
>>>> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3285
>>>> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
>>>> ---
>>>> v1->v2:
>>>>    * use pm preferred profile instead
>>>
>>> Thanks, patch looks good to me:
>>>
>>> Reviewed-by: Hans de Goede <hdegoede@...hat.com>
>>>
>>> Mario, should this go in as a fix for the 6.9 cylce, or is
>>> this for-next material ?  (I'm not sure what to do myself)
>> The main risk with this patch is if there are servers that previously loaded
>> amd-hsmp no longer working because of a BIOS bug to exporting the incorrect
>> profile.  I think this is quite unlikely but not non-zero.
>>
>> To at least give some time for anything like that to be raised I feel this
>> should go to for-next.
> 
> I was also thinking it would be better to route this through for-next.
> 
>> Ideally I do want to see it go to stable kernels after we're all sufficiently
>> happy though.  Random bug reports to me like the ones I added to the commit
>> message get raised mostly by people who compile their own (stable) kernels and
>> enable all the AMD stuff because they have AMD hardware.
>>
>> So how about we target for-next, but also add a stable tag for when it gets
>> merged in the 6.10 cycle?
> 
> That's possible but if you want to retain true control over it, don't add
> stable tag at all now. You can send it on your own volition into stable
> address later once the change is in Linus' tree and your "happy" condition
> is met (Option 3 in Documentation/process/stable-kernel-rules.rst).
> 
> Otherwise, stable will autoselect it the moment it lands into Linus' tree
> and you don't have much control over the timeline from that point on (I've
> seen stable folks to grumble when somebody asked to delay including a
> patch marked for stable, their reasoning was that their autotools keep
> reselecting the patch over and over again).
> 

I don't feel a strong need for a specific timing.  The timeline of of it 
going to the stable trees when 6.10-rc1~ish seems fine by me.