Hi
Thanks for your input!
Peter Stuge peter@stuge.se writes:
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.
Shell scripts are a very bad way to construct binary data structures.
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.
Being open source does not require to be public. FWIW we couldn't publish our tool as a binary-only if it was not licenqed as it currently is (BSD-3 clause). I'm not claiming the binary is open source ofc, but we are committed to publish the code ASAP.
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.
I don't like this very much either, but it looks like it is the best move available. Silicon vendors being overprotective over their IP is a recurring issue. Developing everything on a private branch and doing a big code dump once the silicon vendor gives a green light is an even bigger disservice to the community. - Big code dumps are a huge strain on the community and proved to cause problems in the past. - The rate at which new silicon and platforms are pushed is staggering. If one has to wait for the silicon vendor green light before publishing code the platform might already being to old to be very interesting. We saw this issue in the past where AGESA srubbing took so long that the platforms were not interesting anymore. Intel also publishes FSP glue code without FSP being published. Relying on things not yet published seems to be a necessary compromise to have upstream development in the master branch for new silicon.
One of the things the coreboot project and community does very well at the moment is to develop everything in one master branch, compared to the UEFI world where everything lives in a branch and where there is pretty much 0 community. To keep this upstream development model in line with new silicon development it looks like some compromises are necessary.
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.
If we always have to wait for the silicon vendor to be able to upstream, the platform would already be in production and upstreaming is less interesting for both the vendor and the community. So yes, in a sense it's urgent and this is how a lot of upstream development is going on anyway at the moment.
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.
So no upstream Intel support in coreboot anymore? I'll put it on the agenda tomorrow ;-)
I wish we had enough leverage as a community to change the silicon vendors way, but that is just not the case. I feel however that things improve in the right direction. OSF on server hardware is becoming a thing again, which was not the case at all a few years back.
Sorry, x86 sucks.
On a philosophical note, it's always possible to define goals and desires against which everything sucks. It's a cheap trick of the mind. The goal should be to make tomorrow better than today, even if the progress is small ;-)
Kind regards