linux-kernel - Re: [PATCH v6] drivers/misc: Add Aspeed LPC control driver

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]

Date:   Thu, 16 Mar 2017 17:08:21 +0900
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:     Cyril Bur <cyrilbur@...il.com>, linux-kernel@...r.kernel.org,
        mikey@...ling.org, joel@....id.au, openbmc@...ts.ozlabs.org
Subject: Re: [PATCH v6] drivers/misc: Add Aspeed LPC control driver

On Fri, Feb 17, 2017 at 05:44:57PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2017-02-17 at 14:28 +1100, Cyril Bur wrote:
> > In order to manage server systems, there is typically another
> > processor
> > known as a BMC (Baseboard Management Controller) which is responsible
> > for powering the server and other various elements, sometimes fans,
> > often the system flash.
> 
>  .../...
> 
> > It is important to note that due to the way the Aspeed chip lets the
> > kernel configure the mapping between host LPC addresses and BMC ram
> > addresses the offset within the window must be a multiple of size.
> > Not doing so will fragment the accessible space rather than simply
> > moving 'zero' upwards. This is caused by the nature of HICR8 being a
> > mask and the way host LPC addresses are translated.
> > 
> > Signed-off-by: Cyril Bur <cyrilbur@...il.com>
> 
> Reviewed-by: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> 
> Greg, quick Q for you:
> 
> We will need to also add a mechanism to poke at a few registers
> in the same LPC controllers from userspace.
> 
> Mostly those are "scratch" registers that the BMC is supposed to set to
> specific values to indicates features it supports etc... (or to enable 
> the host BIOS to run in some kind of verbose debug mode).
> 
> Think of it as a communication channel between the BMC and the BIOS
> running on the host.
> 
> The BMC userspace needs to set them to various platform specific
> values as appropriate for a given vendor/system (userspace policy
> from the BMC perspective) during boot and/or change them as the result
> of some user actions (enable debug mode) etc...
> 
> The question here is read/write or sysfs files attached to the
> sysfs node ?
> 
> The former means userspace needs to "seek" to the right magic
> offset to write to one of them which is non-trivial to do from
> simple shell scripts but is a more natural interface.
> 
> It also means the owner/permissions of the /dev entry as set
> by uboot apply which can be nice.
> 
> The latter can expose each register by its name which provides
> a nice way to echo in/out of them from a shell script.
> 
> The drawback is that pretty much restricts access to root.
> 
> What do you recommend ?

That wasn't a quick question :)

I really have no idea, sorry, try some things out and see what seems to
work.

greg k-h