Arthur Heymans wrote: > To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot some > tooling is required to generate both a Key Manifest (A signed binary, that > is checked against a key fused into the ME, holding keys that OEM can use > to sign the BPM) and a Boot Policy Manifest (signed binary, has a digest > of IBBs, Initial Boot Blocks).
This seems like something that could be put together even by a shell script calling openssl the right way. > 9elements has written some open source tooling (BSD-3 clause) to generate > both KM and BPM. The code for this tool is not yet public You can't pretend that something is open source until you've published it. > Intel is currently reviewing this to allow us to make it public, but this > takes time. .. > My question to the community is if it would be ok to allow for the build > system integration code for KM and BPM generation to be integrated into > the master branch before the code to the tooling is made public. I don't think that is at all acceptable, even if it may be technically OK. If you push this problem upstream you would surrender part of your responsibility for delivering an open source solution to your customer, and push the burden of the blobbyness you have created (for your customer) onto the community. I don't think that's a very good move. > At the moment coreboot has code for xeon_sp in the master > branch without a public FSP too Even if everyone at your school smokes in every break it's still bad for your health to start smoking. > we propose to add a binary tool (it's written in go so it's > automatically build as a static binary) to the blobs repo under a > licence similar to the one used for Intel FSP and MCU (allows > redistribution). We hope to remove it ASAP from there and build it > from source from 3rdparty/intel-sec-tools. Especially given that you seem to have good support for pushing Intel forward on this, it doesn't seem urgent to accept what is essentially your problem into upstream. > We'd like to develop as close as possible to the coreboot master branch, > so we hope that this is an acceptable solution to the community. While it is honorable that you want to work as close to master as possible, I do think you should have considered that a lot earlier in this process, before getting tangled up in Intel's net of NDA nonsense. Sorry, x86 sucks. //Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
