Daniel Golle <dan...@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.
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
