Security Working Group - Wednesday May 12 - results

Joseph Reynolds jrey at
Sat May 15 04:50:54 AEST 2021

On 5/12/21 4:35 PM, Michael Richardson wrote:
> Joseph Reynolds <jrey at> wrote:
>      > 1. Security impacts of enabling kexec (load and optionally execute new
>      > kernel) in the BMC's production kernel.  How does this work and play
>      > with secure boot and with IMA?
>      > 2. What are the security impacts of having the proc file system file
>      > /proc/sysrq-triggerwhich can cause kernel panics which can cause the
>      > BMC to terminate processing?
>      > 3. In general, how can you (an operator or the BMC's host system)
>      > recover a BMC which has become unresponsive, for example, because its
>      > kernel processing has failed.  A design introduces using
>      > /proc/sysrq-triggertogether with a recovery kernel installed by kexec.
> This tussle between locking down the system against all intrusions, vs being
> able to fix stuff when in trouble is a serious debate.
> (Based upon how easily random alien technology takes over the Enterprise, we
> know which way Starfleet engineers went.)
> So I suggest that in most cases, the secure boot process should disable
> kexec (and sysrq-trigger!), but that this should be an tunable attribute
> under control of the secure boot process.
> For the majority of data center, business and home users of systems, the risk
> of malware in the bootpath of the BMC exceeds the risk of BMC failures, and
> the cost remediation (taking a machine out of commission when there is a BMC problem).
> Having said that, there is a Right-to-Repair concern, and I really hope that
> manufacturers will provide for a hardware jumper, and for installation of new
> trust anchors.
> But, there is a variety of ways to do that from kernel cmdlines, to being able to
> boot alternate kernels, and perhaps this could be punted down the road for
> the operator that needs (#3).  Perhaps, coming back to my (humour) above, it
> will in fact be Mars Rover missions or Starlink satellites that need it, and
> probably, they can afford to do that work.


Thanks for the NASA, Elon Musk, and Star Trek references.  (I loved the 
Daleks in Star Wars!)

I believe kexec and sysrq-trigger should remain disabled in the OpenBMC 
project defaults.
And the IBM design cited attempts to balance security and usability.

Although I understand there is work in the OCP security project and 
other places to recover a trust anchor, I don't see anything practical 
for OpenBMC to use.

- Joseph

IBM design:

> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr at        |   ruby on rails    [

More information about the openbmc mailing list