measured boot / fTPM and OpenWrt One

[Michael Richardson]

Daniel Golle <daniel at makrotopia.org> wrote:
    >> Well, that's certainly true.  It is not always possible to talk to the
    >> outside world from inside that initial boot enclave.  That's the detail that
    >> we need.
    >> Do we even have a spare GPI(o) pin that can be used for this?
    >> (It can't be used for anything else)

    > While I see your point and believe this is generally possible, it's more
    > than just one bit needed here: It would mean to move the whole GPIO controller
    > into secure land and then make all the other bits again available to non-secure
    > land via SMC calls or something like that...

Since it would be polled once during boot, I don't think that would be
necessary, but I could wrong.  What I am concerned about is some way to
program it as an output and/or change the way pull-ups are done, and then do
a reboot.   That's something that reading the details would produce.

    >>
    >> > The only option of having secure boot enabled would be to allow users to
    >> > permanently disable it, otherwise the resulting hardware would not be
    >> > worth being called "Open", as it would, in fact, be closed.
    >>
    >> The board could ship with it disabled, and the user could blow the fuse to
    >> enable it.

    > If the fuse was documented or the tool for doing this available without
    > signing an NDA with MediaTek, then yes. Both is currently not the case.

That would be my goal of signing the NDA: then prepare a statement and get
MediaTek to approve it.

    >> Some would argue that a board that ships with a private key in storage that
    >> is not, at ship-time, protected, is worthless, but I disagree.  It's a
    >> risks/benefits tradeoff.
    >> (Note: I'm the lead editor for RFC9334)
    >>
    >> I've been down this road a few times with other boards, and the supply chain is
    >> generally very difficult to work with on this.  This is one reason I would
    >> really like to make some progress here.   It helps us get in front of the
    >> situation,   providing a good reference on how to do this sanely.
    >>
    >> And because I think that many of our (other) platforms will find themselves
    >> thinking they are forced down the secureboot path by recent UK, USA
    >> legislation: probably not quite literally by the legislation, but the lawyers
    >> and PHBs will think it.

    > It's a bit funny that the blame for that curse commonly goes to the
    > FCC and UK authorities, because the discussion started with the ETSI
    > Radio Emissions Directive (RED) 10 years ago...

Yes.  I don't think that the CRA and RED are gonna push the same thing at
this point.

    >> > dealing with it kinda means living in denial and darkness. Hence,
    >> > despite all the critizism, I do appreciate your work and effort to allow
    >> > people to get their hands on OP-TEE, fTPM, ... on the OpenWrt One.
    >>
    >> Yes, so this one place that is very hard for people to learn about, because
    >> the pre-uboot steps are hidden :-(

    > ARM TrustedFirmware-A is easy to understand code and released under an
    > Open Source license, we build it from source in OpenWrt for that platform.
    > OP-TEE is an Open Source project as well, and so is Microsoft's fTPM.
    > Just got to put the pieces together, but the pink elephant are the missing
    > documentation and tools for the efuses to make the BootROM validate bl2
    > signature...

I've read the source (OPTEE) code, compiled it, sat at IETF Hackathons with
ARM core people at hackathons who work on this stuff, but *their* test
hardware is almost always virtual.
So, it's exactly that pink elephant is what I'm after.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20240510/2e672f7f/attachment.sig>