From: Joseph Reynolds <jrey@linux.ibm.com>
To: Andrew Jeffery <andrew@aj.id.au>
Cc: Nancy Yuen <yuenn@google.com>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Brad Bishop <bradleyb@fuzziesquirrel.com>,
openbmc <openbmc-bounces+jrey=linux.ibm.com@lists.ozlabs.org>
Subject: Re: Secure boot for BMC
Date: Wed, 13 Feb 2019 18:34:14 -0600 [thread overview]
Message-ID: <02642911831c76d37123735a2964984f@linux.vnet.ibm.com> (raw)
In-Reply-To: <1550013215.2866613.1656755904.44211550@webmail.messagingengine.com>
On 2019-02-12 17:13, Andrew Jeffery wrote:
> On Tue, 12 Feb 2019, at 11:00, Nancy Yuen wrote:
>> We are working on secure boot, but we have a requirement for a Google
>> HW
>> root of trust so I'm not sure if that fits in with these discussions.
>
> I think it would help to have some idea of Google's requirements so the
> project
> can accommodate them where we can, if you can reveal any details. It
> may also
> help inform others (me?) on strategies to secure firmware.
The OpenBMC security working group has discussed various "root of trust"
ideas. The way I understand it, OpenBMC community members are looking
into different solutions including
"Secure Boot" and "Trusted Platform Module" (TPM) solutions, including
Google's OpenTitan chip. See the meeting minutes for details:
https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI
My understanding of the "Secure Boot" concept is that some chip
validates the boot loader's digital signature after loading it and
before jumping into it. Then the boot loader would validate the code it
loads before jumping into it. Etc. A validation failure could either
(a) cause the BMC to fail to boot, or (b) boot the BMC in failsafe mode
where it could not write to its flash or talk to its host. OpenBMC may
also need some way to talk to the chip.
My understanding of TPMs is much more limited. So we are waiting for
proposals.
- Joseph
> Andrew
next prev parent reply other threads:[~2019-02-14 0:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-05 14:14 Secure boot for BMC Brad Bishop
2019-02-05 15:05 ` Teddy Reed
2019-02-05 20:14 ` Supreeth Venkatesh
2019-02-07 1:44 ` Joel Stanley
2019-02-07 2:03 ` Ryan Chen
2019-02-07 18:39 ` Vijay Khemka
2019-02-07 5:06 ` Luke Chen
2019-02-07 21:55 ` Vernon Mauery
2019-02-11 4:57 ` Andrew Jeffery
2019-02-12 0:30 ` Nancy Yuen
2019-02-12 23:13 ` Andrew Jeffery
2019-02-14 0:34 ` Joseph Reynolds [this message]
2019-02-14 23:19 ` Andrew Jeffery
2019-02-18 16:54 ` Avi Fishman
2019-02-12 3:32 ` Ratan Gupta
2019-02-12 13:58 ` George Keishing
2019-02-18 19:27 ` Brad Bishop
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=02642911831c76d37123735a2964984f@linux.vnet.ibm.com \
--to=jrey@linux.ibm.com \
--cc=andrew@aj.id.au \
--cc=bradleyb@fuzziesquirrel.com \
--cc=openbmc-bounces+jrey=linux.ibm.com@lists.ozlabs.org \
--cc=openbmc@lists.ozlabs.org \
--cc=yuenn@google.com \
/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.