From: Joseph Reynolds <jrey@linux.ibm.com>
To: Michael Richardson <mcr@sandelman.ca>, openbmc@lists.ozlabs.org
Subject: Re: Security Working Group - Wednesday May 12 - results
Date: Fri, 14 May 2021 13:50:54 -0500 [thread overview]
Message-ID: <e6484cd8-1962-c45a-a694-6854972b4fc9@linux.ibm.com> (raw)
In-Reply-To: <4508.1620855321@localhost>
On 5/12/21 4:35 PM, Michael Richardson wrote:
> Joseph Reynolds <jrey@linux.ibm.com> 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.
Michael,
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: https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/42948
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
>
next prev parent reply other threads:[~2021-05-14 18:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-12 1:59 Security Working Group - Wednesday May 12 Joseph Reynolds
2021-05-12 18:18 ` Security Working Group - Wednesday May 12 - results Joseph Reynolds
2021-05-12 20:40 ` Patrick Williams
2021-05-14 18:26 ` Joseph Reynolds
2021-05-12 21:35 ` Michael Richardson
2021-05-14 18:50 ` Joseph Reynolds [this message]
2021-05-13 0:25 ` Andrew Jeffery
2021-05-14 19:02 ` Joseph Reynolds
2021-05-16 23:15 ` Andrew Jeffery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e6484cd8-1962-c45a-a694-6854972b4fc9@linux.ibm.com \
--to=jrey@linux.ibm.com \
--cc=mcr@sandelman.ca \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.