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 16:51:48 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Mario Limonciello <superm1@...il.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 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.