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  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:   Fri, 17 Feb 2017 17:44:57 +1100
From:   Benjamin Herrenschmidt <>
To:     Cyril Bur <>,
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 <>

Reviewed-by: Benjamin Herrenschmidt <>

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 ?


Powered by blists - more mailing lists