[RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

On Mo, 2015-03-16 at 13:19 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:08 Mon 16 Mar     , Jan Lübbe wrote:
> > On Mo, 2015-03-16 at 12:14 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 11:19 Mon 16 Mar     , Jan Lübbe wrote:
> > > > Later I'd like to have optional support to switch barebox into a
> > > > "non-secure" or "developer" mode at runtime, which would make hardware
> > > > secrets inaccessible. That could be triggered when a prompt appears or
> > > > when booting for a different source (such as USB fastboot).
> > > 
> > > yeah, I like the idea but for this will have to put a lot of protection so you
> > > can not read/write some part of the memory included barebox itself (in RAM)
> > > 
> > > As in the kernel we have no memmory protection from the shell.
> > 
> > Not necessarily. For example on the MX6 you can trigger a security
> > violation in the CAAM from software. That will clear the OTPMK in its
> > Key-RAM. From that point on you can run any software but you will not be
> > able to decrypt any secret data which was encrypted with the OTPMK.
> > 
> > On hardware which supports something like this, debugging hardware
> > problems is easy and there is no danger of leaking any secret
> > information. If something is useful/possible in any specific project
> > obviously depends on the threat model and hardware capabilities.
> 
> I knonw about the imx6 but that does not mean all the SoC
> unfortunatly.

Yes, every SoC is different. But we should be able to use HW features
when the are available, as sometimes the HW is selected specifically to
used these security features.

> The other pb I see is this one where and do you plan to store the RO x509
> the trusted one.

Sorry, I can't parse this.

> if you use on OTP this means this is enough to ensure secured boot as if you
> can not modify the primary cert of key. No one can brake it. But as you load
> it in ram you need to be sure no one modify it. Even in unlock mode to do only
> allow to boot secure images by expected key.

I should have been more clear: The use case here is to ensure that the
OTPMK-AES-HW-Key is only available when booting with a correct boot
chain. It's OK to boot something else (only the OTPMK needs to be
cleared).

This is a very different goal from making sure that only correctly
signed code is executed.

Both cases need mostly the same verified boot features, only the policy
(especially what to do on signature errors) is different.

> So you may not have secured place to store the cert or key in ram but only
> RAM. so we do need to forbidden this memory acces to everyone except the
> crypto API. if we want ot allow dev mode.

On MX6 this can be done by the HW. Doing this (without TrustZone) purely
in SW seems extremely difficult.

> > > > > the main problem is not console but env you need to drop RW env support
> > > > > and use only RO one, except for keyring support where you will a RW env but
> > > > > not executable and only accesable by crypto API
> > > > > 
> > > > > otherwise you need to use a secured digest such as HMAC/CMAC/OMAC support
> > > > > to sign the env at runtime and ensure the symetric key is secured
> > > > > or encrypt it via aes (did this in the past)
> > > > 
> > > > For an upcoming project we'll add HMAC support to the state storage Marc
> > > > recently submitted.
> > > I've a patch too I need to send it
> > 
> > For environment or state storage?
> envfs

Nice. :)

> > 
> > > but I prefer to wait we have keystore support as this will store the key for
> > > the HMAC otherwise we need to use HW HMAC that store the key in the soc
> > 
> > Another possibility is to use the HW AES key and a compiled in value to
> > derive a per-device HMAC secret. The same approach can also be used in
> > Linux for deriving the IMA/EVM HMAC secret.
> this for me need to be integrated in the keystore to be transparent for the
> rest of the API

That shouldn't be hard. We can look at this in detail after you've
posted that API.

Regards,
Jan
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |