From: Stewart Smith <stewart@linux.vnet.ibm.com>
To: Andrew Jeffery <andrew@aj.id.au>,
Alexander Amelkin <a.amelkin@yadro.com>,
openbmc@lists.ozlabs.org
Subject: Re: BMC Image Signing Proposal
Date: Tue, 30 Jan 2018 15:47:02 +1100 [thread overview]
Message-ID: <87shaoymux.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1517207425.21006.27.camel@aj.id.au>
Andrew Jeffery <andrew@aj.id.au> writes:
> On Fri, 2018-01-26 at 14:07 +0300, Alexander Amelkin wrote:
>> Hi, Anoo!
>>
>> The thoughts are as follows:
>>
>> 1. BMC usually runs in a secured environment where probability of
>> tampering with flash IC contents by means other than BMC's firmware
>> itself is negligible.
>
> This does bring up the issue of developing a threat model to develop
> against; we should probably do that. However, without one, I feel like
> we should design *for* defense in depth and allow people to remove
> protections as they see fit for their environment, rather than make
> potentially compromising assumptions about what that environment is at
> the outset.
>
> For instance, whilst BMCs might typically be isolated from customer
> traffic on a separate LAN, there's still the in-band interface which
> can be used to poke at the BMC. Vulnerabilities in the IPMI stack could
> lead to BMC compromise and undesirable flash writes*. Therefore BMC
> flash integrity remains a valid concern despite network isolation.
>
> * This ties into Michael Brown's talks of isolating daemons to their
> own user/group and enforcing SELinux policy against them.
using isolation technologies that are used by containers may also add
extra depth, and be a good interim solution as SELinux policy is
developed and tuned.
>> 2. U-Boot already performs image checksum validation before booting a
>> FIT image
>
> Typically the rootfs is not part of the FIT, so it will not be checked.
> Some systems supported by OpenBMC directly mount the rootfs rather
> than booting through an initrd, which makes rootfs authentication
> somewhat tricky. Regardless, with signed images we should expand the
> FIT hash check to be a full signature check.
dm-verity would solve that (for a ro rootfs). The read/write parts will
have to be carefully controlled of course, noexec is an obvious
thing. Oh, and not having configuration as executable code and being
*paranoid* about parsing config.
--
Stewart Smith
OPAL Architect, IBM.
next prev parent reply other threads:[~2018-01-30 4:47 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-25 21:15 BMC Image Signing Proposal anoo
2018-01-26 11:07 ` Alexander Amelkin
2018-01-29 6:30 ` Andrew Jeffery
2018-01-29 15:50 ` Simon Glass
2018-01-29 20:59 ` Vernon Mauery
2018-01-30 4:47 ` Stewart Smith [this message]
2018-01-30 6:18 ` Joel Stanley
2018-01-30 16:20 ` Simon Glass
2018-01-30 23:53 ` Stewart Smith
2018-01-31 21:13 ` Adriana Kobylak
2018-02-08 20:27 ` Adriana Kobylak
2018-02-10 1:36 ` Yugi Mani
2018-02-13 22:33 ` Adriana Kobylak
2018-02-13 22:34 ` Adriana Kobylak
2018-02-15 4:07 ` Joel Stanley
2018-02-19 21:04 ` Adriana Kobylak
2018-02-23 1:44 ` Stewart Smith
2018-02-23 20:30 ` Vernon Mauery
2018-02-15 4:10 ` Joel Stanley
2018-02-23 1:47 ` Stewart Smith
2018-02-27 22:13 ` Adriana Kobylak
2018-05-15 2:06 ` Lei YU
2018-05-15 18:18 ` Yugi Mani
2018-05-15 23:03 ` Stewart Smith
2018-05-16 16:02 ` Vernon Mauery
2018-05-18 3:33 ` Lei YU
2018-05-18 16:01 ` Adriana Kobylak
2018-05-18 21:02 ` Vernon Mauery
2018-05-22 6:46 ` Lei YU
2018-05-22 15:30 ` Vernon Mauery
2018-05-22 18:28 ` Vernon Mauery
2018-05-24 17:12 ` Adriana Kobylak
2018-05-24 19:34 ` Vernon Mauery
2018-05-25 7:03 ` Lei YU
2018-05-15 20:00 ` Stewart Smith
2018-01-30 4:39 ` Stewart Smith
2018-01-29 5:56 ` Andrew Jeffery
2018-01-29 21:07 ` Vernon Mauery
2018-01-29 10:44 ` Avi Fishman
2018-01-29 14:40 ` Eugene.Cho
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=87shaoymux.fsf@linux.vnet.ibm.com \
--to=stewart@linux.vnet.ibm.com \
--cc=a.amelkin@yadro.com \
--cc=andrew@aj.id.au \
--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.