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 PHC | |
Open Source and information security mailing list archives
| ||
|
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.
Powered by blists - more mailing lists