speed-bmc-misc driver

speed-bmc-misc driver

[Vijay Khemka]

[-- Attachment #1: Type: text/plain, Size: 191 bytes --]

Hi Andrew,
I saw this driver in LF aspeed Linux and was wondering how to use. Can you please suggest some usage example like device tree entry as well as sysfs interface.

Thanks
-Vijay

[-- Attachment #2: Type: text/html, Size: 1920 bytes --]

Re: speed-bmc-misc driver

[Andrew Jeffery]

Hi Vijay,

On Thu, 10 Oct 2019, at 04:17, Vijay Khemka wrote:
>  
> Hi Andrew,
> 
> I saw this driver in LF aspeed Linux 

What do you mean by "LF aspeed Linux"? The only place this driver lives is
in the OpenBMC kernel tree (openbmc/linux on github).

> and was wondering how to use. Can 
> you please suggest some usage example like device tree entry as well as 
> sysfs interface.

Honestly, I wouldn't recommend using (yet). It can't be upstreamed in its
current form (I've tried), and so using it as is comes with userspace-breaking
changes in the future. I reserve the right to break your machines if you do
make use of it when I get the time to rework the patches.

Having said that, its purpose is to expose arbitrary fields in arbitrary registers
on the BMC to userspace via sysfs. This is useful when the field's value is
entirely determined by userspace policy and there's no need for additional
kernel infrastructure around the configuration.

Originally this was intended to expose to userspace the bits that control the
state of the ASPEED hardware backdoors, but we changed tack on the
solution to CVE-2019-6260 before the bmc-misc idea got very far.

However you can find some slightly abusive uses if you search the dtsis:

https://github.com/openbmc/linux/blob/dev-5.3/arch/arm/boot/dts/aspeed-g5.dtsi#L1682

In that instance we're exposing the SuperIO scratch registers to userspace
using this mechanism. The attributes can be found in sysfs associated with
the devicetree node. I did have a hack to add a sysfs class for them, but that
was even more controversial than the general concept of the "driver" so
you're going to have to cope with changes to the devicetree potentially
breaking userspace unless you're willing to rework the patches yourself.

Hope that helps.

Andrew

Re: speed-bmc-misc driver

[Vijay Khemka]

Hi Andrew,
Thanks for detailed explanation.

Regards
-Vijay


On 10/9/19, 3:46 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote:

    Hi Vijay,
    
    On Thu, 10 Oct 2019, at 04:17, Vijay Khemka wrote:
    >  
    > Hi Andrew,
    > 
    > I saw this driver in LF aspeed Linux 
    
    What do you mean by "LF aspeed Linux"? The only place this driver lives is
    in the OpenBMC kernel tree (openbmc/linux on github).
    
    > and was wondering how to use. Can 
    > you please suggest some usage example like device tree entry as well as 
    > sysfs interface.
    
    Honestly, I wouldn't recommend using (yet). It can't be upstreamed in its
    current form (I've tried), and so using it as is comes with userspace-breaking
    changes in the future. I reserve the right to break your machines if you do
    make use of it when I get the time to rework the patches.
    
    Having said that, its purpose is to expose arbitrary fields in arbitrary registers
    on the BMC to userspace via sysfs. This is useful when the field's value is
    entirely determined by userspace policy and there's no need for additional
    kernel infrastructure around the configuration.
    
    Originally this was intended to expose to userspace the bits that control the
    state of the ASPEED hardware backdoors, but we changed tack on the
    solution to CVE-2019-6260 before the bmc-misc idea got very far.
    
    However you can find some slightly abusive uses if you search the dtsis:
    
    https://github.com/openbmc/linux/blob/dev-5.3/arch/arm/boot/dts/aspeed-g5.dtsi#L1682
    
    In that instance we're exposing the SuperIO scratch registers to userspace
    using this mechanism. The attributes can be found in sysfs associated with
    the devicetree node. I did have a hack to add a sysfs class for them, but that
    was even more controversial than the general concept of the "driver" so
    you're going to have to cope with changes to the devicetree potentially
    breaking userspace unless you're willing to rework the patches yourself.
    
    Hope that helps.
    
    Andrew
    

RE: speed-bmc-misc driver

[Yong Li]

Hi Andrew,

Regarding this bmc-misc driver, I noticed the exported sysfs entries are read-write. Is it possible to export the register value as read-only? Sometimes we only want to display the registers, but users cannot change them.

Thanks,
Yong

-----Original Message-----
From: openbmc <openbmc-bounces+yong.b.li=linux.intel.com@lists.ozlabs.org> On Behalf Of Vijay Khemka
Sent: Thursday, October 10, 2019 9:17 AM
To: Andrew Jeffery <andrew@aj.id.au>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: speed-bmc-misc driver

Hi Andrew,
Thanks for detailed explanation.

Regards
-Vijay


On 10/9/19, 3:46 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote:

    Hi Vijay,
    
    On Thu, 10 Oct 2019, at 04:17, Vijay Khemka wrote:
    >  
    > Hi Andrew,
    > 
    > I saw this driver in LF aspeed Linux 
    
    What do you mean by "LF aspeed Linux"? The only place this driver lives is
    in the OpenBMC kernel tree (openbmc/linux on github).
    
    > and was wondering how to use. Can 
    > you please suggest some usage example like device tree entry as well as 
    > sysfs interface.
    
    Honestly, I wouldn't recommend using (yet). It can't be upstreamed in its
    current form (I've tried), and so using it as is comes with userspace-breaking
    changes in the future. I reserve the right to break your machines if you do
    make use of it when I get the time to rework the patches.
    
    Having said that, its purpose is to expose arbitrary fields in arbitrary registers
    on the BMC to userspace via sysfs. This is useful when the field's value is
    entirely determined by userspace policy and there's no need for additional
    kernel infrastructure around the configuration.
    
    Originally this was intended to expose to userspace the bits that control the
    state of the ASPEED hardware backdoors, but we changed tack on the
    solution to CVE-2019-6260 before the bmc-misc idea got very far.
    
    However you can find some slightly abusive uses if you search the dtsis:
    
    https://github.com/openbmc/linux/blob/dev-5.3/arch/arm/boot/dts/aspeed-g5.dtsi#L1682
    
    In that instance we're exposing the SuperIO scratch registers to userspace
    using this mechanism. The attributes can be found in sysfs associated with
    the devicetree node. I did have a hack to add a sysfs class for them, but that
    was even more controversial than the general concept of the "driver" so
    you're going to have to cope with changes to the devicetree potentially
    breaking userspace unless you're willing to rework the patches yourself.
    
    Hope that helps.
    
    Andrew
    

Re: speed-bmc-misc driver

[Andrew Jeffery]

On Wed, 16 Oct 2019, at 14:34, Yong Li wrote:
> Hi Andrew,
> 
> Regarding this bmc-misc driver, I noticed the exported sysfs entries 
> are read-write. Is it possible to export the register value as 
> read-only? Sometimes we only want to display the registers, but users 
> cannot change them.

I strongly advise against using the driver for the reasons I outlined to Vijay.
For OpenPOWER systems we're using it, but with the knowledge that I'll
need to fix userspace when I fix the driver.

I'd prefer not to go adding features to the existing code now for that
reason, but I think controlling the read-write/read-only nature of attributes
is a good idea.

If you want to improve the "driver" so that it can be upstreamed I'm happy
to help out with that. Basically it should be changed to a light API that
enables creation of these types of attributes that can be called from
drivers for the device in question.

Andrew