Security Working Group - Wednesday May 12 - results
andrew at aj.id.au
Thu May 13 10:25:41 AEST 2021
It tends to be useful to Cc the developers doing the work. Posting to
the list without Cc'ing relevant people leaves discovery of your
discussion to chance, where as adding them on To: or Cc: does two
1. Raises the chance that they'll pay attention to your discussion
2. Removes the impression that you're intentionally talking past them
Please try to engage the relevant people directly in the discussion by
adding them in To: or Cc.
On Thu, 13 May 2021, at 03:48, Joseph Reynolds wrote:
> On 5/11/21 8:59 PM, Joseph Reynolds wrote:
> > This is a reminder of the OpenBMC Security Working Group meeting
> > scheduled for this Wednesday May 12 at 10:00am PDT.
> > We'll discuss the following items on the agenda
> > <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/edit>,
> > and anything else that comes up:
> Three items were discussed. You might want to start with item 3 first
> to introduce the first two. Summary:
> 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?
Have you engaged with OpenBMC's kernel developers? They might be are
interested in this problem. I'm vaguely aware of some work-in-progress
patches that allows kexec to load FIT images, which can be signed and
validated. This would mitigate execution of arbitrary kernels and also
helps avoid the problem of shipping multiple kernel binaries or
extracting artefacts from a FIT to pass to kexec.
> 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.
To be clear, the use of /proc/sysrq-trigger is a temporary hack to
reboot the BMC in the absence of kexec/kdump. Once those features are
merged the application implementing this behaviour can invoke kexec
directly. The slight advantage of /proc/sysrq-trigger is that with or
without kexec/kdump enabled the BMC will reboot, and if kexec/kdump are
enabled then it will automatically take advantage of them.
In the specific case p10bmc platforms the host has access to a GPIO
tied to the BMC's EXTRST line, so with or without this software feature
the host can mount denial of service attacks of arbitrary length. This
hardware design places the BMC and host firmware in the same trust
More information about the openbmc