From: Michael Richardson <mcr@sandelman.ca>
To: Joseph Reynolds <jrey@linux.ibm.com>, openbmc@lists.ozlabs.org
Subject: Re: Security Working Group - Wednesday May 12 - results
Date: Wed, 12 May 2021 17:35:21 -0400 [thread overview]
Message-ID: <4508.1620855321@localhost> (raw)
In-Reply-To: <8febdc9d-08bb-4094-9cad-7e6035c5bd71@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]
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.
--
] 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 [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2021-05-12 21:35 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 [this message]
2021-05-14 18:50 ` Joseph Reynolds
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=4508.1620855321@localhost \
--to=mcr@sandelman.ca \
--cc=jrey@linux.ibm.com \
--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.