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] [day] [month] [year] [list]

Message-ID: <1523371986.11062.101.camel@kernel.crashing.org>
Date:   Wed, 11 Apr 2018 00:53:06 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Arnd Bergmann <arnd@...db.de>
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, 2018-04-10 at 15:06 +0200, Arnd Bergmann wrote:
> 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.

Ok, so we could use a subsystem as a grouping method in sysfs, that
does make some amount of sense ;-)

That said, fundamentally, it is going to be exposed by whatever creates
the syscon for the SoC, so yes, a "SoC" driver is probably the right
thing to instanciate that thing, as those knobs are very much SoC
specific. Though I do want to keep the actual definition DT based at
least for Aspeed.

As for finding the commonalities, the connundrum here is that we juts
don't have enough experience of platforms with different kinds of BMCs
to do that (provided there's anything to find).

So we can wait a few years until we do and keep out-of-tree crap
drivers, or just solve the immediate problem in a semi-reasonable way,
and maybe make things evolve as we get more SoC's into the picture.

My issue right now is that we need products out of the door (and not
just we IBM, but everybody using OpenBMC) and we are just carrying
various horrid out of tree hacks to do so, and that needs urgent
fixing.

The main worry I have with my own idea here is that it's too easily
abused for things that shouldn't get in there. But I can't find a way
around that, we'll just have to be vigilant I suppose...

Cheers,
Ben.