linux-kernel - Re: [PATCH] Introduce support for Systems Management Driver over WMI for Dell Systems

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: <52fb287e-e683-63bc-3641-90abd78c605a@redhat.com>
Date:   Tue, 22 Sep 2020 10:57:33 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     "Limonciello, Mario" <Mario.Limonciello@...l.com>,
        Divya Bharathi <divya27392@...il.com>,
        "dvhart@...radead.org" <dvhart@...radead.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "Bharathi, Divya" <Divya.Bharathi@...l.com>,
        "Ksr, Prasanth" <Prasanth.Ksr@...l.com>,
        Richard Hughes <rhughes@...hat.com>,
        Jared Dominguez <jaredz@...hat.com>
Subject: Re: [PATCH] Introduce support for Systems Management Driver over WMI
 for Dell Systems

Hi,

On 9/21/20 5:26 PM, Limonciello, Mario wrote:

<snip>

I will do another more detailed reply in another email, but I would like to focus
at the main pain point here, which is the using a generic sysfs-ABI/class vs using
a Dell specific sysfs-ABI.

>> I guess a could way to look at the generic sysfs firmware attributes
>> class I'm proposing is looking at it as a lowest common denominator
>> solution. With the addition of vendor specific extensions so that
>> vendors (e.g. Dell) are not limited to only offering functionality
>> offered by the generic, shared ABI. Does that make sense ?
>>
>> Regards,
>>
> 
> I really think that trying to fit all the vendors into the same interface is going
> to stifle areas for innovation in the firmware and kernel space in the name of
> "simplicity" which really only goes as far as the kernel side.  Userspace has
> to carry delta between vendors no matter what, so why introduce a LCD then?
> 
> Just as easily we could have:
> /sys/devices/platform/dell-wmi-sysman/attributes/
> 
> Which works 90% the same as:
> /sys/devices/platform/lenovo-wmi-sysman/attributes/

So the reason why I want a class interface for this is to allow say
FleetCommander to have a generic plugin implementing that 90%, so
no deps, only support plain admin-password authentication.

Allowing such a generic plugin requires 2 things:

1) Ensuring that the 90% overlapping functionality offers a 100%
identical userspace ABI, thus a shared sysfs ABI definition

2) That userspace has a generic way to enumerate devices/drivers
implementing this shared sysfs ABI, and we have a standard
mechanism for enumerating drivers which implement a standard ABI,
that is we make them register class devices under /sys/class/<abi-name>.

I have not heard any convincing arguments against why would
should not or can not have these 2 things. All I'm hearing is
a vague fear that this may "stifle areas for innovation in the firmware
and kernel space".

Honestly I have the feeling we are going in circles in this discussion
and I really do not understand why you are so dead set against having
a common sysfs ABI/class for this?

In part of the snipped text you write "Having to de-feature the sysfs
interface", but I have not asked you to remove any features anywhere in
this thread!

So I really do not understand where this fear of not being able to
implement certain, possibly Dell specific, features comes from?

You mentioned that the way the dependencies are expressed are
highly Dell specific, so I suggested allowing having vendor
extensions like dell-modifiers and dell-value_modifiers. The whole
idea behind allowing vendor-extensions is actually the exact
opposite of de-featuring the sysfs interface.

Regards,

Hans