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

Message-ID: <1487313897.23576.122.camel@kernel.crashing.org>
Date:   Fri, 17 Feb 2017 17:44:57 +1100
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Cyril Bur <cyrilbur@...il.com>, gregkh@...uxfoundation.org
Cc:     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, 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 ?

Cheers,
Ben.