From: "Andrew Jeffery" <andrew@aj.id.au>
To: "Joseph Reynolds" <jrey@linux.ibm.com>, openbmc@lists.ozlabs.org
Subject: Re: Security Working Group - Wednesday May 12 - results
Date: Thu, 13 May 2021 09:55:41 +0930 [thread overview]
Message-ID: <99f4fa9d-9fc2-4092-be1f-d3246379206a@www.fastmail.com> (raw)
In-Reply-To: <8febdc9d-08bb-4094-9cad-7e6035c5bd71@linux.ibm.com>
Hi Joseph,
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
things:
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
domain.
Andrew
next prev parent reply other threads:[~2021-05-13 0:27 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
2021-05-13 0:25 ` Andrew Jeffery [this message]
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=99f4fa9d-9fc2-4092-be1f-d3246379206a@www.fastmail.com \
--to=andrew@aj.id.au \
--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.