linux-kernel - Re: [PATCH 0/5] platform/x86: introduce asus-bioscfg

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8273ed57-4c65-41da-ad7d-907acf168c07@redhat.com>
Date: Tue, 16 Jul 2024 11:20:19 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: "Luke D. Jones" <luke@...nes.dev>, platform-driver-x86@...r.kernel.org
Cc: corentin.chary@...il.com, ilpo.jarvinen@...ux.intel.com,
 mario.limonciello@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] platform/x86: introduce asus-bioscfg

Hi Luke, Mario,

On 7/16/24 7:16 AM, Luke D. Jones wrote:
> This is the first major patch I've ever done with the intention of
> introducing a new module, so it's highly likely I've made some mistakes
> or misunderstood something.
> 
> TL;DR:
> 1. introduce new module to contain bios attributes, using fw_attributes_class
> 2. deprecate all possible attributes from asus-wmi that were added ad-hoc
> 3. remove those in the next LTS cycle
> 
> The idea for this originates from a conversation with Mario Limonciello
> https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/
> 
> It is without a doubt much cleaner to use, easier to discover, and the
> API is well defined as opposed to the random clutter of attributes I had
> been placing in the platform sysfs.

This is a bit of a novel use of the fw_attributes_class and I'm not
entirely sure of what to think of this.

The fw_attributes_class API was designed for (mostly enterprise)
x86 machines where it is possible to change all BIOS settings directly
from the OS without entering the BIOS.

Here some ACPI or WMI function is present to actually enumerate all
the BIOS options (which can be set this way) and get there type.

IOW there is not a static list of options inside the driver, nor
is there special handling in the driver other then handling differences
per type.

And if a new BIOS version has new options or a different machine model
has different options then these are discovered automatically.

This new use is quite different from this. Although I do see that
at least for the attributes using WMI_STORE_INT() + WMI_SHOW_INT()
that there is quite some commonality between some of the attributes.

I see how using the existing firmware-attributes class API definition
for this, including allow tweaking this with some of the fwupd
firmware-attributes class commandline util work Mario did is a useful
thing to have.

I guess using the firmware-attributes class for this is ok, but
this _must_ not be named bioscfg, since the existing hp-bioscfg
driver is a "classic" firmware-attributes drivers enumerating all
the options through BIOS provided enumeration functions and I want
the name to make it clear that this is not that. And the Dell
implementation is called dell-wmi-sysman so lets also avoid sysman
as name.

Maybe call it "asus-bios-tunables" ?   And then if Asus actually
implements some more classic firmware-attributes enumerable interface
we can use "asus-bioscfg" for that.

Mario, Ilpo what is your opinion on this ?

Regards,

Hans