Hi
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). At the moment these are included as binaries by the build system.
Obviously this only works if the IBB hasn't changed. If it changed, you'd need to regenerate the BPM. 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 as it was written using NDA documentation. Intel is currently reviewing this to allow us to make it public, but this takes time. It will be part of the 3rdparty/intel-sec-tools submodule.
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. CBnT is an optional feature on Intel hardware and is implemented as an optional feature in coreboot. The tool is standalone and coreboot can still be built fine without it.
At the moment coreboot has code for xeon_sp in the master branch without a public FSP too, with the promise that it will be publicly released later on by Intel. Compared to that the situation would be a little better: 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.
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.
So TL;DR: - Is (temporarily) adding a tool to the blobs repo ok? - Is integrating an (optional) not yet open tool into the build system ok?
Let me know what you think.
Kind regards.
Arthur Heymans
9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: arthur.heymans@9elements.com Phone: +49 234 68 94 188 Mobile: +32 478499445
Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar
Datenschutzhinweise nach Art. 13 DSGVO
Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans < arthur.heymans@9elements.com>:
So TL;DR:
- Is (temporarily) adding a tool to the blobs repo ok?
If it matches the requirements of the blobs repo wrt. license terms and documentation, I don't see why not from a formal perspective. It's telling though (in the sense of a Freudian slip) that you put the "temporarily" in parentheses already: interim solutions like these tend to survive their best due date ;-)
- Is integrating an (optional) not yet open tool into the build system ok?
This one is IMHO the bigger issue: that tool will only run on Linux/x86(-64?), and probably only with a select set of libc implementations. While we have portability issues every now and then, they're always accidentally introduced because our testing isn't good enough while adding this to the build flow deliberately makes all other platforms second tier build hosts.
Regards, Patrick
Regarding Intel approval of the content, We (Facebook) has been working with Intel to get this moved forward as soon as possible.
Thanks, Jonathan
From: Patrick Georgi via coreboot coreboot@coreboot.org Reply-To: Patrick Georgi pgeorgi@google.com Date: Tuesday, February 9, 2021 at 2:40 AM To: Arthur Heymans arthur.heymans@9elements.com Cc: coreboot coreboot@coreboot.org Subject: [coreboot] Re: Intel CBnT tooling and dealing with NDA
Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans <arthur.heymans@9elements.commailto:arthur.heymans@9elements.com>: So TL;DR: - Is (temporarily) adding a tool to the blobs repo ok? If it matches the requirements of the blobs repo wrt. license terms and documentation, I don't see why not from a formal perspective. It's telling though (in the sense of a Freudian slip) that you put the "temporarily" in parentheses already: interim solutions like these tend to survive their best due date ;-)
- Is integrating an (optional) not yet open tool into the build system ok? This one is IMHO the bigger issue: that tool will only run on Linux/x86(-64?), and probably only with a select set of libc implementations. While we have portability issues every now and then, they're always accidentally introduced because our testing isn't good enough while adding this to the build flow deliberately makes all other platforms second tier build hosts.
Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Hi,
On 09.02.2021 11:02, Arthur Heymans wrote:
Hi
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). At the moment these are included as binaries by the build system.
Obviously this only works if the IBB hasn't changed. If it changed, you'd need to regenerate the BPM. 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 as it was written using NDA documentation. Intel is currently reviewing this to allow us to make it public, but this takes time. It will be part of the 3rdparty/intel-sec-tools submodule.
What is the diff between BtG and CBnT manifests format? Is the work that we (3mdeb) did, not usable?
Best regards,
Hi Michal,
mind pointing me to the tooling you make for *creating* these manifests?
Am Di., 9. Feb. 2021 um 11:46 Uhr schrieb Michal Zygowski < michal.zygowski@3mdeb.com>:
Hi,
On 09.02.2021 11:02, Arthur Heymans wrote:
Hi
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). At the moment these are included as binaries by the build system.
Obviously this only works if the IBB hasn't changed. If it changed, you'd need to regenerate the BPM. 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 as it was written using NDA documentation. Intel is currently
reviewing
this to allow us to make it public, but this takes time. It will be part of the 3rdparty/intel-sec-tools submodule.
What is the diff between BtG and CBnT manifests format? Is the work that we (3mdeb) did, not usable?
Best regards,
-- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Christian,
On 09.02.2021 11:58, Christian Walter wrote:
Hi Michal,
mind pointing me to the tooling you make for *creating* these manifests?
There is a whole intel_bootguard topic: https://review.coreboot.org/q/topic:intel_bootguard In particular have a look at these patches: - Tool: https://review.coreboot.org/c/coreboot/+/43403 - Hook manifest creation into build system: https://review.coreboot.org/c/coreboot/+/43404
The manifests layout is implemented in the tool. Although it creates the v1.0 manifests and AFAIK CBnT required v2.1 format, but this tool can be a good base, isn't it?
Best regards,
Hi Michal,
this _could_ have been a good starting point - however we decided to integrate this into the Converged Security Suite (github.com/9elements/converged-security-suite http://github.com/9elements/converged-security-suite) which already is part of coreboot as a 3rdparty module. However even if we _would_ extend your tooling - NDA issues still are not resolved. As Arthur pointed out, we would hope to integrate this as a binary as a temporary solution, until Intel clears out the NDA issues. And also in the sense of moving forward, I would like to choose Golang over C in this case.
Best, Chris
Am Di., 9. Feb. 2021 um 12:14 Uhr schrieb Michal Zygowski <michal.zygowski@3mdeb.com mailto:michal.zygowski@3mdeb.com>:
Hi Christian,
On 09.02.2021 11:58, Christian Walter wrote:
> Hi Michal, > > mind pointing me to the tooling you make for *creating* these manifests? > There is a whole intel_bootguard topic: https://review.coreboot.org/q/topic:intel_bootguard https://review.coreboot.org/q/topic:intel_bootguard In particular have a look at these patches: - Tool: https://review.coreboot.org/c/coreboot/+/43403 https://review.coreboot.org/c/coreboot/+/43403 - Hook manifest creation into build system: https://review.coreboot.org/c/coreboot/+/43404 https://review.coreboot.org/c/coreboot/+/43404
The manifests layout is implemented in the tool. Although it creates the v1.0 manifests and AFAIK CBnT required v2.1 format, but this tool can be a good base, isn't it?
Best regards,
-- Michał Żygowski Firmware Engineer https://3mdeb.com https://3mdeb.com | @3mdeb_com
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org mailto:coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org mailto:coreboot-leave@coreboot.org
On 09.02.21 13:14, Christian Walter wrote:
Hi,
As Arthur pointed out, we would hope to integrate this as a binary as a temporary solution, until Intel clears out the NDA issues.
I really don't like this idea. As it's a special case for the time being, this can live in some extra branch, possibly extra repo, just for those few folks who really need it right now.
Adding binary cruft to the mainline removed the pressure for folks like Intel (which is an exceptionally ugly player in this regard) to clear up everyhing. They should feel the presure of being ignored (at best), until they provide a really clean solution. They should learn once for all that those things never should have been under NDA in the first place.
Note: this has nothing to do with (dis)repsect regarding your work.
And also in the sense of moving forward, I would like to choose Golang over C in this case.
hmm, golang in general is a bit problematic in distro context. (anyone, who tried clean packaging and build process of golang and go applications for distros like Debian, knows what I'm talking about :p) ... it's a nice language, but getting their own ecosystem isle (damn, they even built their own wannabe package manager) play along nicely with distros is a pretty huge and non-trival job.
Personally, for that kind of job, I'd prefer something like Python :p
--mtx
Hi,
thanks for the feedback. I am totally on your site that this is not an ideal solution - however the coreboot community has to think about how to work around these issues. Stating that this just does not get merged into the tree is not a good solution, as we are not moving forward on these topics and can not compete with proprietary solutions if we are holding on to the statement that also tooling needs to be open-source.
Don't get me wrong - I love open-source and don't understand why these things, especially when they are security critical, are closed-source. That is against what I learned from as a security researcher - and this is what security does for years now - open-sourcing the concepts, algorithms and so on.
So - I am always a fan on moving forward, and also moving fast forward. However: we cleared out the NDA issues and released the tool into the public [1]. That being said - NDA issues are off the table now.
---
Golang did quite some work on the dependency system and I know it tends to be confusing. But things get better - plus python is not any better on that. But don't get me started on that ;)
Best,
Chris
[1]: https://github.com/9elements/converged-security-suite/
On 2/23/21 12:26 PM, Enrico Weigelt, metux IT consult wrote:
On 09.02.21 13:14, Christian Walter wrote:
Hi,
As Arthur pointed out, we would hope to integrate this as a binary as a temporary solution, until Intel clears out the NDA issues.
I really don't like this idea. As it's a special case for the time being, this can live in some extra branch, possibly extra repo, just for those few folks who really need it right now.
Adding binary cruft to the mainline removed the pressure for folks like Intel (which is an exceptionally ugly player in this regard) to clear up everyhing. They should feel the presure of being ignored (at best), until they provide a really clean solution. They should learn once for all that those things never should have been under NDA in the first place.
Note: this has nothing to do with (dis)repsect regarding your work.
And also in the sense of moving forward, I would like to choose Golang over C in this case.
hmm, golang in general is a bit problematic in distro context. (anyone, who tried clean packaging and build process of golang and go applications for distros like Debian, knows what I'm talking about :p) ... it's a nice language, but getting their own ecosystem isle (damn, they even built their own wannabe package manager) play along nicely with distros is a pretty huge and non-trival job.
Personally, for that kind of job, I'd prefer something like Python :p
--mtx
On 23.02.21 12:35, Christian Walter wrote:
Hi,
Stating that this just does not get merged into the tree is not a good solution, as we are not moving forward on these topics and can not compete with proprietary solutions if we are holding on to the statement that also tooling needs to be open-source.
how did competition become a criterium for coreboot ?
I can only speak for myself here: my interest in coreboot is nothing more than having a properly working solution (which, of course, includes maintainability on a very high position on the requirements list) for certain boards, that I'm interested in. And, if possible, punch some ugly corps like Intel in the face, as a nice collateral benefit. Anything else is out of my scope - I've given up trying to heal the world.
Don't get me wrong - I love open-source and don't understand why these things, especially when they are security critical, are closed-source. That is against what I learned from as a security researcher - and this is what security does for years now - open-sourcing the concepts, algorithms and so on.
Good, but you should also know that all of that only really works, if done consequently. For Intel SoC, eg. it means: as long ME remains closed, the platform remains inherently insecure, because you've got non-trustworthy folks having control over the most critical part.
So - I am always a fan on moving forward, and also moving fast forward.
I prefer, not just forward, but in the right direction for my goals. And not fast, but well though, clean and consequent steps.
However: we cleared out the NDA issues and released the tool into the public [1]. That being said - NDA issues are off the table now.
Great. So, what's still left to do here ?
Golang did quite some work on the dependency system and I know it tends to be confusing. But things get better - plus python is not any better on that. But don't get me started on that ;)
Okay, it's been a while since I touched golang. Having to upgrade the compiler, just to get some arbitrary program running, which leads to repackage a long list of compiler versions built in sequential order, since I neither use some bleeding-edge-distro, nor any precompiled binaries (except those from official distro repo, or built myself), doesn't exactly sound inviting.
Python had similar problems, but (at least for the vast majority of packages) it's under pretty good control. I've already scripted up an (almost) fully automatic import and debian packaging that's capable of packaging large portion of pypi.org, with minimal set of manual intervention (yes, there still are ugly exceptions). Of course, we could do something similar w/ go, but defeating the horribly mishabit of "vendoring" (useless manual code duplication) isn't so trivial.
Just having a quick look at the code ...
#1: I hope you're aware of that things like "goreleaser", that completely bypass the distro infrastructure and call lowlevel tools directly, are exactly an example for the already mentioned distro hostility (BTW: ruby folks, which are even worse, already stated openly, how they hate distros and wished to get rid of them), that makes me very reluctant of getting anywhere near golang.
#2: if you wanna attract people actually using it, you should perhaps tell clearly how to build it and provide a nice Makefile. (dont expect everybody to keep in mind how the 10.001th build system works :p)
#3: about half an hour of external downloads from arbitrary sources, before actual build even starts, isn't actually inviting. IIRC, our discussion was about some tool for just signing an image.
#4: several coffees later, 'go build' breaks:
can't load package: package github.com/9elements/converged-security-suite/v2: unknown import path "github.com/9elements/converged-security-suite/v2": cannot find module providing package github.com/9elements/converged-security-suite/v2
#5: autogenerated stuff should not go into a source repo
#6: trying to run the fist step in the circleci script gives:
go: downloading github.com/fatih/camelcase v1.0.0 go: downloading github.com/xaionaro-go/gosrc v0.0.0-20201124181305-3fdf8476a735 go: downloading github.com/fatih/structtag v1.2.0 go: downloading github.com/xaionaro-go/unsafetools v0.0.0-20200202162159-021b112c4d30 # github.com/xaionaro-go/gosrc ../../../go/pkg/mod/github.com/xaionaro-go/gosrc@v0.0.0-20201124181305-3fdf8476a735/directory.go:106:19: undefined: os.UserHomeDir ../../../go/pkg/mod/github.com/xaionaro-go/gosrc@v0.0.0-20201124181305-3fdf8476a735/directory.go:149:33: undefined: importer.ForCompiler
At that point, I've given up. Not usable for production :(
[ BTW: did you see that golang.org openly supports an Soros-financed violent terror organisation, that already devastated several major cities in the US last year and also stormed into the US capitol ? I really don't like to have anything to do with those people. ]
--mtx
Hi Enrico,
(list to bcc)
not speaking about the technical difficulties you face with golang or the general topic of blob use here, just one thing:
Don't post conspiracy theories here. Well, two things: We also do not punching here (except for cards, maybe, if we're in the mood for some retro computing.)
It took me some deliberation whether or not to moderate you, but I also didn't want to deal with the (very realistic risk of you) whining that you're being censored. You're not: Later messages with such content will drop out of the moderation queue without further comment, but you still have an entire Internet (minus coreboot.org) at your disposal to try to disseminate your world view.
Am Di., 23. Feb. 2021 um 20:38 Uhr schrieb Enrico Weigelt, metux IT consult info@metux.net:
that already devastated several major
cities in the US last year and also stormed into the US capitol ?
I really don't like to have anything to do with those people. ]
If you're really worried about being associated (even several times remote) with organizations that are (or may be) responsible for devastation of cities, I have really bad news for you:
coreboot, originally LinuxBIOS, was initially funded by the US DoE through LANL (https://www.coreboot.org/FAQ#Who_is_funding_coreboot.3F) of which Wikipedia (https://en.wikipedia.org/wiki/Los_Alamos_National_Laboratory) has this to say: "initially organized during World War II for the design of nuclear weapons as part of the Manhattan Project". There are few organizations that can lay claim to "devastation of major cities" to the degree that they can.
It was later kept alive through projects indirectly (and maybe directly) paid for by the German government, with purposes - among others - like controlling Patriot ground-to-air missiles (the laptop seen at https://youtu.be/0RfPSXL6yLw?t=67 looks like a Roda RK8 series device and probably runs coreboot). I'm trying to put it mildly, but Patriot isn't typically used for home improvement.
Nowadays the support of companies like Google, Facebook and Amazon is elemental in keeping coreboot usable on current platforms (even if there are caveats with those platforms). Some people claim that these companies devastate societies and economies: Under the loose-association philosophy that you seem to live by, some brick & mortar store owners (the backbone of inner city living infrastructure) might have a word or two to say about you being affiliated with a project that is used by Amazon. Some people in San Francisco (a major US city) are rather unhappy about Google and Facebook as well, due to a perception that there's some negative impact of their headquarter on cost of living in the area. (And if this section contains a larger amount of weasel words than usual note that I'm not trying to take a position here, just present a point of view)
Therefore if you don't like to have anything to do with people who devastate cities, you better look elsewhere (and given that Free Software and Open Source licensing in general forbids "field of endeavour" clauses you'll have a hard time living that philosophy anywhere in the FLOSS ecosystem)
Regards, Patrick
Hi Christian,
Christian Walter wrote:
thanks for the feedback. I am totally on your site that this is not an ideal solution - however the coreboot community has to think about how to work around these issues.
I disagree; this isn't an issue for the community, it's /your/ issue in /your/ project that you're (presumably) billing /your/ customer for.
Stating that this just does not get merged into the tree is not a good solution, as we are not moving forward on these topics and can not compete with proprietary solutions if we are holding on to the statement that also tooling needs to be open-source.
I think you're forgetting your role as an expert within the ecosystem; you have to make sure to raise this issue or learning to your customer.
And if you've made recommendations, suggestions or decisions that led into a temporary dead-end then you have to own that fact towards your customer.
However: we cleared out the NDA issues and released the tool into the public [1].
That's good news!
So the original question in this thread is no longer the right one to ask, correct?
Published tooling means that you are/have submitting patches which use the tooling to prepare more trusted artifacts?
If yes, it would seem that the known-bad short term solution was unneccessary and that the community decision to reject it was correct. Woop!
//Peter
Patrick Georgi via coreboot coreboot@coreboot.org writes:
Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans
So TL;DR: - Is (temporarily) adding a tool to the blobs repo ok?
If it matches the requirements of the blobs repo wrt. license terms
and documentation, I don't see why not from a formal perspective.
It's telling though (in the sense of a Freudian slip) that you put
the "temporarily" in parentheses already: interim solutions like these tend to survive
their best due date ;-)
I was told this typically takes Intel a few months.
- Is integrating an (optional) not yet open tool into the build
system ok?
This one is IMHO the bigger issue: that tool will only run on
Linux/x86(-64?), and probably only with a select set of libc implementations. While we
have portability issues every now and then, they're always
accidentally introduced because our testing isn't good enough while adding this to the
build flow deliberately makes all other platforms second tier build
hosts.
Good point! Tools build with go include the go runtime so they should be fully standalone. Adding different ARCH + OS is very easy with go, so adding other platforms can be done very quickly if desired.
Kind regards
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
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
On 09.02.21 20:40, Arthur Heymans wrote:
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.
It's us moving though, and not the silicon vendors. Sure, they move too, but for every step they take in the open-source direction, we take two steps closer to their blobs. For the OCP contributions, I'd even estimate a 1-to-5 steps ratio: They did not only re-introduce NDA blobs to be run inside coreboot, they also seem to want every blob around coreboot to be integrated. And, AFAIK, soon also runtime resident blobs. What would be left? the coreboot console, an SMM loader and a PCI allo- cator. I would not call that coreboot, not even blobboot or shimboot. We once had such a component internally, we called it "crpldr". Feel free to fill some vowels.
Things are moving. Not into the right direction, though. Every compromise is made on our side.
Nico
On 09.02.21 20:40, Arthur Heymans wrote:
Hi,
Shell scripts are a very bad way to construct binary data structures.
Maybe a python or perl script ?
Being open source does not require to be public.
How so, exactly ?
If only a few parties have access to the source code, eg. some vendor shares with its business partners, then it's just "shared code".
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.
If just the binary is published, without source code, then it is NOT open source. Yes, BSD clause permits reclosing of formerly open software - that's why we have other license models like GPL. (GPL code isn't OSS, but Free software - it remains free and can't be closed again w/o breaking the license).
I don't like this very much either, but it looks like it is the best move available.
Move in which direction, exactly ? What exactly can we - the free software community - gain from that ?
The only thing I see right now is one can recompile the whole thing, under certain circumstances, possibly with *some* modifications. Maybe, for some individuals, better than nothing, but conceptionally hasn't much to do w/ FOSS.
Bad side: folks like Intel, can now lay back and say "hey, those FOSS jerks have got a piece of food and can shut up again". For us, mission failed.
Silicon vendors being overprotective over their IP is a recurring issue.
Yes, that's their problem. They've created this mess themselves, and they should't expect us, the public, the FOSS community, cleaning up their mess, even for free (beer).
I don't wanna speculate what's going on in their heads (more precisely the heads of some suit-wearing folks high upstairs - not the tech guys), but the whole idea of "protected IP" for those things (anything that one needs to develop drivers) is completely nonsense. The only practical reason for that is defrauding their silently own paying customers and forcing them into an dishonest dependency. In other words: peventing the *owners* of those products to fully excersise their legal rights from their ownership title. (Apple products are a woderful example for that kind of abuse: you legally *buy* a device, but effectively you've just suscribed a few services).
In your case, the situation very pretty simple: all you need is to create a simple signature of some file and put everything that way, that the SoC designers happend to choose. This is neither an invention nor an piece of art, or something else that's egligably for any kind of legal IP protection. No notable level of creativity. It's just a simple formula.
If we buy into this and accept proprietary implementations of simple formulas, then we're lost and can give up the whole project. If we let that pass, we soon need some proprietary app just for computing the surface area of a circle.
Instead, I'd like to propose a different approach:
You could sign a dozen of images and publish them along with the key pair. So we can find out the formula on our own and type it down in some convenient language. No NDA problems anymore. You didn't tell any "business secret", and they got another lecture that their ridiculous behaviour didn't give them anything but useless costs, and the whole world laughts about them.
The strongest weapon against any kind of oppression is the oppressed just don't play along with their oppressors anymore. Just stop doing what they want. It's that simple.
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.
Of course, you should send cleanly written, easily digestable patches, as usual. If your queue is quite long, then it just takes a while for review and merge. I don't see any problem with that.
OTOH, your quick+dirty proposal is just an ugly hack, that might be usable for some folks, but far away from what I'd consider maintainable.
- 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.
The best option of course is not buying those HW, until it is mainlined. Personally, I'm circumventing x86 where ever I can. The more people doing that, the more pressure on Intel and AMD.
We saw this issue in the past where AGESA srubbing took so long that the platforms were not interesting anymore.
Yes, AGESA is a pile of shit. It's the same scenario as above - I don't see any beneign reason of not publishing the necessary specs, so we could implement the *necessary* pieces our own. What do we actually need it for ? At the end, we only need to do a few boring early HW setups, clocks, timings, regulators, etc. Nothing spectacular, once your know the correct values and their order.
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.
Only for Intel and AMD. I don't recall any similar case ARM world, where we needed any blobs just for SoC bringup. (GPUs etc often still are a big mess, but that's far out of scope here)
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.
UEFI never had community. It's always been design-by-committee. That's why it's such a ridiculous misdesign.
To keep this upstream development model in line with new silicon development it looks like some compromises are necessary.
Depends on how exactly you define "in line". Personally, I don't think that having the newest stuff as quick as possible is an worthy goal at all. (actually, I newer buy any bleeding edge hw - wait until the next generation is out, so there's enough of practical experience with it and prices fall down - applies to all kind of technology).
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.
I see that differently: my primary criterion for hw purchase decision (when being just in the user role) is available free software support, or at least open specs. Without that, there gotta be a damn good reason for buying it. A silicon vendor who's not playing with open cards just isn't trustworthy to me.
By the way: we'd also should talk about, how you actually define "upstreaming". Just having it merged into master branch once, isn't enough, IMHO (from my practical experience w/ certain silicon vendors, that's seems one of their primary misunderstandings). It has to fit well into they way, how things are handled in upstream. It has to be actively maintained in order to keep it that ways. And that's the point where such blobs become really ugly.
So yes, in a sense it's urgent and this is how a lot of upstream development is going on anyway at the moment.
Why not just keeping it in a different branch, that's rebased with each new mainline release ?
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 ;-)
Not quite, but without the pseudo help of such corporations.
I wish we had enough leverage as a community to change the silicon vendors way, but that is just not the case.
We can't ever change them, anyways. No matter how many people we're (or how many users we have) - we can only change ourselves. And we can decide whether give them any single penny anymore, and what we suggest to others.
I've decided (for me personally) to leave Intel alone, let'em die lonely. Maybe I change my mind, when they fully open up ME. Until then, remains on the blacklist.
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 ;-)
No, just alone from purely technical perspective, x86 is misdesigned in many ways - including it's spinoffs like ACPI or UEFI. Yes, it gives lots of computing power on a single dice, and you get get it anywhere on the next corner, buts thats it.
--mtx
On 09.02.21 11:02, Arthur Heymans wrote:
Hi,
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.
Please define 'integration' and 'made public'
Can we already get this tool anywhere, as binary ? (just the source not published yet ?)
IMHO, adding blobs to a source tree is always problematic, even more for stuff executed by the build process. Blobs for things like early init are something I could only live with as a temporary measure, hoping somebody takes the time for rever-engineering. (things microcode or firmware for some very special controller are different issue).
With 'integration' I guess you mean, the tool is called somewhere in the build process. In that case, IMHO it could be expected as an external program (just like compiler, linker, etc) and being an optional dependency: eg. having an option like 'rebuild foobar' with a clear documentation the dependency on that external tool, where to get it, where it runs, etc.
Once it's really open souce and can be built anywhere, I could imaging letting the coreboot build system also fetch and build that tool when needed.
--mtx
-
Arthur Heymans -
Arthur Heymans -
Christian Walter -
Enrico Weigelt, metux IT consult -
Jonathan Zhang (Infra) -
Michal Zygowski -
Nico Huber -
Patrick Georgi -
Peter Stuge