* Re: [PATCH] firmware/dmi: Allow overriding vendor provided DMIIDs
[not found] <20220206104636.19146-1-sp1rit@disroot.org>
@ 2022-02-08 13:56 ` Jean Delvare
0 siblings, 0 replies; only message in thread
From: Jean Delvare @ 2022-02-08 13:56 UTC (permalink / raw)
To: Florian sp1rit; +Cc: sp1rit, linux-kernel
Hi Florian,
On Sun, 06 Feb 2022 11:46:36 +0100, Florian sp1rit wrote:
> Various device vendors do not properly fill out the SMBIOS/DMI
> information in the bios firmware of their devices. This leads to
> issues, like finding "System manufacturer System Product Name" under
> "Hardware Information" in GNOME Settings, which made it's way there
> (over a few dbus detours) from DMIIDs provided from the kernel.
>
> This patch intoduces a handful kernel parameters that allow
> overriding these values with user defined ones, similar to changing
> values in HKLM\HARDWARE\DESCRPTION\System\Bios or
> $WINDIR/system32/OEMINFO.ini on Microsoft Windows.
>
> The alternative would either be patching the vendor provided bios
> CAP file, which seems quite dangerous and might not even work if
> the update has to be signed. Or introducing some kind of
> configuration file to systemd-hostnamed to allow the overriding of
> the values from userspace. However that might work for this usecase,
> but most software will not use hostnamed, since simply reading a
> file is a lot simpler that having to rely on dbus to query system
> information.
I'm absolutely not convinced by the idea. This is fixing the problem at
the wrong place. If the BIOS is reporting wrong information, and you
really care about it, then complain to the manufacturer and have them
provide a BIOS update to fix it. If they can't be bothered (which I
know is often the case) then this might be a good reason to consider a
different manufacturer next time.
To be honest, GNOME Settings displaying invalid system information on
crappy systems is the least of my concerns. Even if this happened on a
system I was running, I wouldn't bother passing kernel parameters to
work around that.
Furthermore this is creating a lot of room for risk and abuse. Such as
using the UUID of one system on another, or accidentally claiming that a
given system is a completely different one and getting unrelated kernel
drivers loaded and probing hardware in unexpected ways. I don't want to
have to deal with the fallout of that.
So this is a no from me, sorry.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply [flat|nested] only message in thread