openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dhananjay Phadke <dphadke@linux.microsoft.com>
To: Patrick Williams <patrick@stwcx.xyz>
Cc: Christopher J Engel <cjengel@us.ibm.com>,
	"Chia-Wei, Wang" <chiawei_wang@aspeedtech.com>,
	Andrew Jeffery <andrew@aj.id.au>,
	openbmc@lists.ozlabs.org, U-Boot-Denx <u-boot@lists.denx.de>,
	"Alex G." <mr.nuke.me@gmail.com>, Simon Glass <sjg@chromium.org>
Subject: Re: [PATCH] image: Control FIT signature verification at runtime
Date: Mon, 14 Feb 2022 19:12:48 -0800	[thread overview]
Message-ID: <06616971-2f88-740d-e805-d229aa86d985@linux.microsoft.com> (raw)
In-Reply-To: <YgriLTCF5hvtPCMm@heinlein>

On 2/14/2022 3:13 PM, Patrick Williams wrote:
> On Mon, Feb 14, 2022 at 11:14:53AM -0800, Dhananjay Phadke wrote:
>> On 2/13/2022 5:13 PM, Andrew Jeffery wrote:
>>
>> We can decouple HW RoT and runtime control on enforcing secure boot
>> (requiring one or keys) on FIT image. Conflating two raises lot of
>> questions.
> 
> I won't claim to be a security expert but I don't understand this statement.
> What are the "lots of questions" that are raised?
> 
>> There's not much case for disabling HW RoT, which implies the bootloader
>> (U-Boot or more) has to be trusted after board is manufactured
>> (OTPstraps, especially OTPCFG0[6], are programmed).
>>
>> There's indeed a case for disabling secure boot on OS FIT image -
> 
> Why wouldn't you want to replace the bootloader just as easily as you can
> replace the kernel / OS itself?  I don't understand why this is more special
> than any other software.  Bootloaders are replaced on "real" systems all the
> time.  There are multiple efforts to be able to replace BIOS/UEFI with a free
> implementation as well.
> 
> I would consider the "HW RoT" to be the software in ROMs and not anything
> which can be replaced, like u-boot.  Why are you extending it to include u-boot?

Agree that ROM maybe just immutable code + some logic, but almost surely
lacks high level stack e.g. network stack to communicate securely and
change boot behavior (remote unlock).

Bootloader (U-Boot in Aspeed case) happens to be the first component
with rich stack to enable such workflows without / before physical
intervention.

It also means, for defense against physical attacks (e.g. replace boot
SPI), first mutable component (bootloader) must be trusted by immutable
component earlier in boot chain. Further secure boot chain may have its
own control knobs from compile or runtime.


> 
>> If bootloader is trusted, it's possible to remotely push the policy to
>> disable runtime FIT image secure boot. Such policy push must use secure
>> transport (someway authenticated) and storage (simplest U-Boot env).
>> This is helpful in cases like booting diagnostic images if board has to
>> be RMA'ed and diagnostic images won't be signed by production keys.
> 
> For second-hand / recycled hardware, I'm not sure the bootloader _is_ trusted.
> It is also possible that I punt on some aspects of supply-chain security and
> simply replace it all when it arrives in my hands.  ie. If I can securely
> replace all the bits, I really don't care if it was tampered with in transit.
> 
>> There's a key-requirement policy already implemented [1].
>>
>> [1]
>> https://lore.kernel.org/u-boot/cover.1597643014.git.thiruan@linux.microsoft.com/
>>
>> Board code can patch "required-policy" = none at runtime based
>> appropriate logic.
>>

[...]

> 
> Isn't this jumper proposal just like the TCG Physical Presence requirements?
> This is a software implementation and requires a particular hardware design for
> it to be done right, but it seems to be along the same lines.

I'm supporting idea of having control on FIT verification, just pointed
that it maybe done by board code by just patching U-Boot control FDT,
either the "required-policy" property at /signature or "required"
property in individual key nodes.


Regards,
Dhananjay



  parent reply	other threads:[~2022-02-15  3:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31  3:41 [PATCH] image: Control FIT signature verification at runtime Andrew Jeffery
2022-02-07  1:07 ` ChiaWei Wang
2022-02-08 21:55   ` Andrew Jeffery
2022-02-12 22:54     ` Dhananjay Phadke
2022-02-12 18:55 ` Alex G.
2022-02-14  1:13   ` Andrew Jeffery
2022-02-14 19:14     ` Dhananjay Phadke
2022-02-14 23:08       ` Andrew Jeffery
2022-02-14 23:13       ` Patrick Williams
2022-02-15  0:21         ` Andrew Jeffery
2022-02-15  3:12         ` Dhananjay Phadke [this message]
2022-02-15  3:25           ` Andrew Jeffery
2022-02-28  1:29             ` Andrew Jeffery
2022-02-28 22:12               ` Alex G.
2022-02-28 22:42                 ` 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=06616971-2f88-740d-e805-d229aa86d985@linux.microsoft.com \
    --to=dphadke@linux.microsoft.com \
    --cc=andrew@aj.id.au \
    --cc=chiawei_wang@aspeedtech.com \
    --cc=cjengel@us.ibm.com \
    --cc=mr.nuke.me@gmail.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=patrick@stwcx.xyz \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).