linux-kernel - Re: How to expose various BMC chip controls ?

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:   Tue, 10 Apr 2018 15:06:51 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Jeffery <andrew@...id.au>,
        Joel Stanley <joel.stanley@....ibm.com>,
        Jeremy Kerr <jeremy.kerr@....ibm.com>
Subject: Re: How to expose various BMC chip controls ?

On Tue, Apr 10, 2018 at 2:57 PM, Benjamin Herrenschmidt
<benh@...nel.crashing.org> wrote:
> On Tue, 2018-04-10 at 13:29 +0200, Arnd Bergmann wrote:

>> In the cases where an ad-hoc interface is needed, I can see
>> two options: we can stick something in drivers/soc that exposes
>> it in the least ugly way, completely specific to that particular
>> SoC, or we can create a new subsystem from "random BMC
>> slave-side interfaces" and have it maintained by you all (leave
>> me out of the picture, except if you are looking for ideas).
>
> I don't think there enough commonality in these things to create a "BMC
> slave interface" class that is anything other than a bunch of sysfs
> files.
>
> That's why I ended up with my personal conclusion/preference of just
> having the syscon "driver" for the SoC just expose a table of a dozen
> or so such knobs, and use the DT to describe them to abstract a bit the
> difference between SoC models/revisions and how they are wired up in a
> given platform.

The idea with having a subsystem for it would be to group stuff together
in one directory and have that owned by people that care about it,
even if there is little commonality between the things it's used for.

That might be more useful than having it in drivers/misc/ or
drivers/soc/, especially when it comes to recognizing things that
are common between different BMC hardware implementations
or (host) firmware stacks that were initially thought to be more
specific.

>> In any case, I think it makes most sense to discuss new interfaces
>> between the people working on the competing BMC implementations,
>> mainly to see if some functionality can be abstracted in a common
>> way or not.
>
> So we have some ideas of what competing BMC *chip* vendors do since
> OpenBMC people communicates with other vendors.
>
> We know a lot less about BMC SW stacks, but those are a rat nest of
> closed source & GPL stuff that doesn't get upstream (or even released
> sometimes ... ahem ...). Having had access to some vendor code in the
> past, I can tell you that you really don't want to look at what's going
> on in there ;-)

Sure, I really only meant the hardware capabilities here.

      Arnd