On 11:43 Fri 13 Mar , Jan Lübbe wrote: > On Fr, 2015-03-13 at 11:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > > On 11:10 Fri 13 Mar , Jan Lübbe wrote: > > > On Fr, 2015-03-13 at 10:56 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > > > Having an ASN1 parser for DER/x509 is a huge amount of complexity I > > > > > would not want in a bootloader. Just take a look at the problems the > > > > > SSL-CAs and browsers had with different interpretations of the same > > > > > cert. > > > > > > > > der is nothing few under lines > > > > > > Sorry, I can't parse this. > > > > > > > x509 a few more as it's based on DER > > > > > > Could you show me that code? > > let me finish to clean it > > and rebase it > > Sure. > > > > > > The FIT format (and corresponding public key in the bootloader's DT) has > > > > > been adopted by depthcharge and u-boot, because it handles the > > > > > requirements and nothing more. > > > > > > > > if you want to add this format you can but via the keychain loader not in the > > > > code as today you do have soc such as imx that store the key in OTP as DER > > > > > > The IMX does not store keys in OTP. It stores a SHA(1 or 256) hash over > > > a table of "super root keys". This is irrelevant for barebox, as this is > > > already handled by the ROM code. > > it's does as you can use it as hw IP to check the kernel > > RSA checking in HABv4 (i.e. MX6) is done in software by the ROM code. > For the first step we should only support RSA in software to keep the > complexity down. > > > yes you store a hash but you do can use it in barebox. > > Yes, you could use it in barebox. What is the use case where you would > do this instead of having the key compiled-in (and verified together > with the code by the ROM)? yes let the rom code handle it if you want, it will be a HW implementation specific to IMX with HABv4 The framework must not be limited to FIT only but FIT is just one of secure boot supported > > > other SoC (i can mention the name NDA) does store the key in the OTP of the > > SoC programmed at production time of the SoC itself. > > with HW RSA accelerator > > OK, please leave HW RSA as a future step. The current framework is already ready for this mostly > > > > > and u-boot is not the best reference EVER. > > > > > > Depthcharge is much more relevant here, as it's used as a coreboot > > > payload on chromebooks. > > > > does not make it more relevant is the term of key format > > > > the Standard are x509, PGP and der/pem for ages > > > > and as said we can support it but make it the only one NO WAY > > I'd prefer PGP to x509 anyway. ;) I do prefer PGP too but unfortunately it's not a flexibal format > > If we can have x509 and FIT (with key in DT) without too much additional > complexity and have each optional at compile time, I'm not against it. > I'll wait for your code. > > > > > > What is your use-case for which you need to add keys at runtime? > > > > > > > > simple you want to allow user to put their own key > > > > or use a CA to handle allowed key > > > > > > > > if you want to replace grub this is critical > > > > > > We have customers which require that do not allow runtime loading of > > > keys. So it should be possible to disable runtime loading at compile > > > time. > > yeah of cource but the feature need to be here IMHO > > OK. > > > and honestly to respect the opensource if you allow this you MIGHT be > > compliant with GPLv3 > > s/compliant/non-compliant/ ? compliant we had layer checking it for one of my client in the pase, I'll ask for the result > > How you need to handle that in practice depends on the context of the > whole system. > > > it's more user friendly > > For my own customer I always recommand to have a board uniq key that you > > can provide to each end customer upon request to it can install it's own > > linux. Even if the key is not replaceble. > > Yes, that's nice if the production work flow in the factory can do this, > but it's not always possible. if you use x509 you can you just need to have a unique ID on the HW and then use a x509 object to store it. then signed it with you CA. As only validated keys can be used, you can easly give a generated key for a specific HW. And this key will be valid only for this HW. Already did it in the past on u-boot and barebox Best Regards, J. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
