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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <e9f4fb37-5277-a7f0-2bec-8a6909b4e674@linux.intel.com>
Date: Tue, 16 Jul 2024 18:11:46 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Hans de Goede <hdegoede@...hat.com>
cc: "Luke D. Jones" <luke@...nes.dev>, platform-driver-x86@...r.kernel.org, 
    corentin.chary@...il.com, mario.limonciello@....com, 
    LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/5] platform/x86: introduce asus-bioscfg

On Tue, 16 Jul 2024, Hans de Goede wrote:
> 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 ?

What you suggested sounds good to me.

-- 
 i.