From: Stewart Smith <stewart@linux.vnet.ibm.com>
To: Patrick Williams <patrick@stwcx.xyz>, Chris Austen <austenc@us.ibm.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: OpenBMC Image Management
Date: Mon, 30 Jan 2017 16:47:13 +1100 [thread overview]
Message-ID: <87o9ypw13y.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170127030706.GB5504@heinlein.lan>
Patrick Williams <patrick@stwcx.xyz> writes:
> On Wed, Jan 25, 2017 at 05:50:46PM -0600, Chris Austen wrote:
>> "openbmc" <openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org> wrote on
>> 01/25/2017 04:15:27 PM:
>>
>> Are there any security goals that need to be considered?
>>
>
> There are a few different aspects to security that I can think of:
>
> 1. Is there a way to identify and reject an invalid image (Define
> "invalid") before it is applied onto the system?
>
> 2. Is there a way to identify an applied image has been tampered with?
>
> 3. Is there a way for an image to expose a security flaw in the code
> itself (such as by "fuzzing") to cause unintended effects?
I think the biggest opportunity for fuzzing and security analysis will
be in BMC<->HOST interfaces.
It'd be great if every BMC<->HOST interface could be fuzzed in sim or in
userspace.
> A few statements to answer your question:
>
> * If there is a fundamental flaw in any of these regards with our design,
> we would like to know about it and will fix it.
>
> * #1 is typically solved through image signing and a one-time
> verification at the time an image is applied. Issue
> openbmc/openbmc#356 is meant to implement this and would be a
> later feature on top of Adriana's proposed work.
>
> * #2 is typically solved through "Secureboot" or similar
> functionality.
> * The Power9 processor can implement Secureboot itself, so the IBM
> team currently has no plans to implement additional per-use
> verification of the Host firmware contents [in PNOR] by the BMC.
> * IBM also does not currently plan to include BMC Secureboot for
> the Witherspoon machine's initial delivery.
dm-verity (a device-mapper target taht cryptographically verifies each
filesystem block) could be a way to very easily get most of what's
needed here.
https://lwn.net/Articles/459420/
https://source.android.com/security/verifiedboot/
> * Rick Altherr from Google has been contributing support for
> U-Boot "FIT" images, which provide something like Secureboot
> verification for the kernel and initramfs images.
Combined with dm-verity, we'd be a long way towards a remotely
trustworthy BMC (well, trust-worthy in the way that it's running a
*known* set of vulnerabilities :)
--
Stewart Smith
OPAL Architect, IBM.
next prev parent reply other threads:[~2017-01-30 5:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 22:15 OpenBMC Image Management Adriana Kobylak
2017-01-25 23:50 ` Chris Austen
2017-01-27 3:07 ` Patrick Williams
2017-01-30 5:47 ` Stewart Smith [this message]
2017-01-31 18:16 ` Patrick Williams
2017-01-31 18:33 ` Rick Altherr
2017-06-13 18:10 ` Adriana Kobylak
2017-06-13 21:45 ` Stewart Smith
2017-06-18 19:48 ` Adriana Kobylak
2017-06-19 5:44 ` Stewart Smith
2017-06-20 14:38 ` Adriana Kobylak
2017-06-20 15:03 ` Chris Austen
2017-07-11 0:53 ` Adriana Kobylak
2017-06-21 5:42 ` Stewart Smith
2017-07-11 1:47 ` Adriana Kobylak
2017-07-11 21:47 ` Stewart Smith
2017-08-02 18:04 ` Adriana Kobylak
2017-08-02 17:23 ` OpenBMC Image Management - Witherspoon Adriana Kobylak
2017-08-03 0:19 ` Stewart Smith
2017-08-03 1:53 ` Andrew Geissler
2017-09-21 20:40 ` Adriana Kobylak
2017-01-26 10:43 ` OpenBMC Image Management Anton D. Kachalov
2017-01-26 15:33 ` Adriana Kobylak
2017-01-26 21:38 ` Rick Altherr
2017-01-30 5:50 ` Stewart Smith
2017-01-30 5:51 ` Stewart Smith
2017-01-30 5:54 ` Stewart Smith
2017-01-30 5:55 ` Stewart Smith
2017-06-16 22:18 ` Maxim Sloyko
2017-06-20 14:34 ` Adriana Kobylak
2017-08-02 17:15 ` Adriana Kobylak
2017-08-03 0:14 ` Benjamin Herrenschmidt
2017-08-03 5:55 ` Patrick Williams
[not found] ` <20170803055546.A99FA112040@b01ledav004.gho.pok.ibm.com>
2017-08-03 5:59 ` Benjamin Herrenschmidt
2017-08-07 22:02 ` Milton Miller II
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=87o9ypw13y.fsf@linux.vnet.ibm.com \
--to=stewart@linux.vnet.ibm.com \
--cc=austenc@us.ibm.com \
--cc=openbmc@lists.ozlabs.org \
--cc=patrick@stwcx.xyz \
/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.