I'd like to open discussion on a revamp of the text on the main coreboot.org Web site. I had a brief discussion on IRC recently with some basic agreement from a couple of people that the text on that page has likely bitrotted enough compared to the current status and goals of coreboot to no longer be useful.
I bring this up due to confusion in less technical circles that I've been having to correct over the past week or so. Specifically, these statements taken in isolation:
"Fast, secure and flexible OpenSource firmware"
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
present a very different picture than the reality of the project at the moment for modern platforms. If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements above at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware. As those of us dealing with the reality of modern x86 and ARM platforms understand more fully, this could not be farther from the truth.
One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One is the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for vendor binaries, which is not well understood at this time among much of the open source community, but seems to have significant support from vendors like Google, Intel, and AMD.
Complicating matters, the trademark "coreboot" is currently known to some members of the public as a trusted (albeit limited in compatibility) fully open source replacement for their exiting board level firmware. When the word "coreboot" is used, very few people think of the glue project. Do we want to dilute / shift the coreboot trademark / branding to the glue part of the project, or do we want to somehow reserve "coreboot" for the native init part of the project? I don't have an answer here, I'm just trying to state the facts as I currently see them for further discussion.
I would propose the following changes, and welcome discussion on these topics:
The heading could read something like "Flexible, open source frameworks for system firmware"
and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology."
Thoughts?
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com
This sounds like a good idea to me.
I think that it might be a good idea to present the two things as seperate components. In my opinion it makes sense to leave the init framework as 'coreboot'. However the firmware glue framework should probably be called something diffierent, like 'core firmware framework' (or if someone has a shorter yet still descriptive name, that would be good).
While these two code bases could live in the same repository, distinguishing them on the front page would probably go a long way to helping people understand what the thing they are using provides. 'Coreboot' provides an auditable init system, while 'core firmware framework' provides an auditable framework for glueing firmware, typical vendor blobs, together.
Platforms that support the coreboot native init could be labled as having actual coreboot support, while those that use the glue logic only, and thus require vender blobs to do the actual init, would be labled as having core firmware framework support (or again, another name for the new umbrella term).
It would be nice if we can more prominently show libre-friendly systems with coreboot. There have been some ideas proposed about how to do this, for example this one by Carl-Daniel: https://mail.coreboot.org/pipermail/coreboot/2010-October/060894.html
Now that our infrastructure is much better than it was nearly a decade ago, maybe we can reconsider some ideas that would have previously involved a lot of tedious manual labor. For example, perhaps a matrix of boards and blob dependencies can be auto-generated using `make what-jenkins-does` (or something similar) and looking at the resulting .config file for each board. From there, boards with no blob dependencies (at least no 3rdparty/{blobs,fsp} dependencies) can be put on a list of "libre platforms" linked from the homepage.
Just thinking out loud...
Hello,
This seems to be a fairly accurate assessment of the situation, imo.
It's disappointing to see people shocked by inclusion of binary components and left with a very negative impression. I've seen coreboot particularly derided by people who first learn about libreboot from the FSF and arrive with high expectations. Perhaps acknowledging the split and that right now x86 is a best effort in bad situation can help with this.
This both points out the platforms which are "fully free" and manages expectations upfront with other architectures. POWER systems that exist like the Talos II and any future openPOWER implementations are arguably far more "free" than anything on the RYF list (every thinkpad runs proprietary EC firmware, including the X220), and may be very appealing to those looking for a "maximum freedom" solution. The only other thing to do is be specific about what firmware modules are included in various other platforms and provide information needed to make an informed decision for a given threat model.
As Patrick Georgi noted:
FSP is a mixed bag in that it enabled going on with contemporary hardware but also seemed to have killed all motivation to reverse engineer chipset bringup - or maybe that's due to the omnipresent ME...
I think acknowledging the split may also generate interest in improving this situation. It's great if it prompts people to investigate proprietary components or pressure their vendors for better documentation.
A nitpick: Perhaps
As an Open Source project it provides a flexible framework for integration of necessary vendor-specific firmware modules, and...
instead of
As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and...
is more specific?
I not sure about naming. There was mention a while back of Oreboot, but not everything fully open source is also C-free. Which one of the two would be coreboot-lite? :P
Sincerely, -Matt
On Sat, Aug 31, 2019 at 5:54 PM Timothy Pearson < tpearson@raptorengineering.com> wrote:
I'd like to open discussion on a revamp of the text on the main coreboot.org Web site. I had a brief discussion on IRC recently with some basic agreement from a couple of people that the text on that page has likely bitrotted enough compared to the current status and goals of coreboot to no longer be useful.
I bring this up due to confusion in less technical circles that I've been having to correct over the past week or so. Specifically, these statements taken in isolation:
"Fast, secure and flexible OpenSource firmware"
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
present a very different picture than the reality of the project at the moment for modern platforms. If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements above at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware. As those of us dealing with the reality of modern x86 and ARM platforms understand more fully, this could not be farther from the truth.
One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One is the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for vendor binaries, which is not well understood at this time among much of the open source community, but seems to have significant support from vendors like Google, Intel, and AMD.
Complicating matters, the trademark "coreboot" is currently known to some members of the public as a trusted (albeit limited in compatibility) fully open source replacement for their exiting board level firmware. When the word "coreboot" is used, very few people think of the glue project. Do we want to dilute / shift the coreboot trademark / branding to the glue part of the project, or do we want to somehow reserve "coreboot" for the native init part of the project? I don't have an answer here, I'm just trying to state the facts as I currently see them for further discussion.
I would propose the following changes, and welcome discussion on these topics:
The heading could read something like "Flexible, open source frameworks for system firmware"
and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology."
Thoughts?
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements above at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware.
If people are confusing coreboot with ME, PSP, AGESA, FSP, BinaryPI, etc. then that is indeed a problem.
One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One is the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for vendor binaries, which is not well understood at this time among much of the open source community, but seems to have significant support from vendors like Google, Intel, and AMD.
I don't see the latter as a project goal, it's just something that enables coreboot to be used in non-libre platforms.
Complicating matters, the trademark "coreboot" is currently known to some members of the public as a trusted (albeit limited in compatibility) fully open source replacement for their exiting board level firmware. When the word "coreboot" is used, very few people think of the glue project. Do we want to dilute / shift the coreboot trademark / branding to the glue part of the project, or do we want to somehow reserve "coreboot" for the native init part of the project?
Similar points have been made about Linux supporting binary modules. I'm not convinced that conflating the project's openness with that of third-party modules is helpful.
The heading could read something like "Flexible, open source frameworks for
system firmware"
and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology."
Adding the word "framework" somewhere in there could be useful. I'm don't think the rest needs to change, at least not much. The goal is always to provide maximum openness, auditability, and control. The hard part is conveying that one cannot achieve this goal 100% on many platforms (especially in the x86 world).
----- Original Message -----
From: "David Hendricks" david.hendricks@gmail.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "coreboot" coreboot@coreboot.org Sent: Saturday, August 31, 2019 7:08:55 PM Subject: Re: [coreboot] Web site revamp
If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements above at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware.
If people are confusing coreboot with ME, PSP, AGESA, FSP, BinaryPI, etc. then that is indeed a problem.
One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One is the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for vendor binaries, which is not well understood at this time among much of the open source community, but seems to have significant support from vendors like Google, Intel, and AMD.
I don't see the latter as a project goal, it's just something that enables coreboot to be used in non-libre platforms.
I think you've touched on the heart of the problem here. What exactly does "using coreboot" mean? As an analogy, if I use WSL (which exposes Linux-like interfaces but is actually a proprietary NT kernel under the hood) am I really "using Linux"? To purposefully go to an extreme, if a vendor comes up with 128MB of proprietary firmware that calls ~10 lines of coreboot code in the end to handoff to an OS, is that "using coreboot"?
From a business perspective I see severe trademark dilution in an attempt to cater to non-libre platforms. Is this the direction we want to go? From our side at Raptor, if coreboot becomes synonymous with proprietary firmware / glue, we'd need to seriously reconsider our promotion / association given our focus on fully open / owner controlled computing (note this is not intended as a threat in any way, I'm simply trying to highlight that going to one extreme to capture x86 platforms as "coreboot" may make coreboot itself unattractive for open platform vendors).
Complicating matters, the trademark "coreboot" is currently known to some members of the public as a trusted (albeit limited in compatibility) fully open source replacement for their exiting board level firmware. When the word "coreboot" is used, very few people think of the glue project. Do we want to dilute / shift the coreboot trademark / branding to the glue part of the project, or do we want to somehow reserve "coreboot" for the native init part of the project?
Similar points have been made about Linux supporting binary modules. I'm not convinced that conflating the project's openness with that of third-party modules is helpful.
From where I sit, Linux can get away with it because the ratio of open code to binary modules is so high, and has remained extremely high with no indication of significant change. I'd argue that this hard-to-reach goal being attained for so long is reflective of excellent leadership from Linus and the other folks in charge of Linux.
The heading could read something like "Flexible, open source frameworks for
system firmware"
and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology."
Adding the word "framework" somewhere in there could be useful. I'm don't think the rest needs to change, at least not much. The goal is always to provide maximum openness, auditability, and control. The hard part is conveying that one cannot achieve this goal 100% on many platforms (especially in the x86 world).
Where I take issue still is that we're nowhere near 100%. On modern platforms we're somewhere below 50% and oftentimes well below that. The wording is confusing and misleading as-is. Another bad analogy: if I start a project for "maximum control" of an airliner, but the reality of the situation is the best level of control I can ever attain is how far back my seat reclines, then the wording is purposefully grandiose, opaque and (IMO) rather weasel-worded to make it sound like the project is doing something far more than it can ever accomplish. Do we really need to stoop to this level with coreboot? What is to be gained by hiding the reality of the situation from non-technical users visiting the website?
Where I take issue still is that we're nowhere near 100%. On modern platforms we're somewhere below 50% and oftentimes well below that. The wording is confusing and misleading as-is. ... What is to be gained by hiding the reality of the situation from non-technical users visiting the website?
While I think this is true, it raises another question:
Users can expect a linux live CD to work, but flashing coreboot carries risk of creating a brick. It's a process which for beginners isn't inaccessible but does require a lot of research. What are the anticipated characteristics of the various audiences who visit the site?
To take an extreme stance, could non-technical users one day be directed to coreboot distributions like Librecore or vendors like Purism/System76?
-Matt
On Sat, Aug 31, 2019 at 8:23 PM Timothy Pearson < tpearson@raptorengineering.com> wrote:
----- Original Message -----
From: "David Hendricks" david.hendricks@gmail.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "coreboot" coreboot@coreboot.org Sent: Saturday, August 31, 2019 7:08:55 PM Subject: Re: [coreboot] Web site revamp
If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements
above
at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware.
If people are confusing coreboot with ME, PSP, AGESA, FSP, BinaryPI, etc. then that is indeed a problem.
One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One
is
the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for
vendor
binaries, which is not well understood at this time among much of the
open
source community, but seems to have significant support from vendors
like
Google, Intel, and AMD.
I don't see the latter as a project goal, it's just something that
enables
coreboot to be used in non-libre platforms.
I think you've touched on the heart of the problem here. What exactly does "using coreboot" mean? As an analogy, if I use WSL (which exposes Linux-like interfaces but is actually a proprietary NT kernel under the hood) am I really "using Linux"? To purposefully go to an extreme, if a vendor comes up with 128MB of proprietary firmware that calls ~10 lines of coreboot code in the end to handoff to an OS, is that "using coreboot"?
From a business perspective I see severe trademark dilution in an attempt to cater to non-libre platforms. Is this the direction we want to go? From our side at Raptor, if coreboot becomes synonymous with proprietary firmware / glue, we'd need to seriously reconsider our promotion / association given our focus on fully open / owner controlled computing (note this is not intended as a threat in any way, I'm simply trying to highlight that going to one extreme to capture x86 platforms as "coreboot" may make coreboot itself unattractive for open platform vendors).
Complicating matters, the trademark "coreboot" is currently known to
some
members of the public as a trusted (albeit limited in compatibility)
fully
open source replacement for their exiting board level firmware. When
the
word "coreboot" is used, very few people think of the glue project. Do
we
want to dilute / shift the coreboot trademark / branding to the glue
part
of the project, or do we want to somehow reserve "coreboot" for the
native
init part of the project?
Similar points have been made about Linux supporting binary modules. I'm not convinced that conflating the project's openness with that of third-party modules is helpful.
From where I sit, Linux can get away with it because the ratio of open code to binary modules is so high, and has remained extremely high with no indication of significant change. I'd argue that this hard-to-reach goal being attained for so long is reflective of excellent leadership from Linus and the other folks in charge of Linux.
The heading could read something like "Flexible, open source frameworks
for
system firmware"
and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open,
auditable
boot process with maximum control over the technology."
Adding the word "framework" somewhere in there could be useful. I'm don't think the rest needs to change, at least not much. The goal is always to provide maximum openness, auditability, and control. The hard part is conveying that one cannot achieve this goal 100% on many platforms (especially in the x86 world).
Where I take issue still is that we're nowhere near 100%. On modern platforms we're somewhere below 50% and oftentimes well below that. The wording is confusing and misleading as-is. Another bad analogy: if I start a project for "maximum control" of an airliner, but the reality of the situation is the best level of control I can ever attain is how far back my seat reclines, then the wording is purposefully grandiose, opaque and (IMO) rather weasel-worded to make it sound like the project is doing something far more than it can ever accomplish. Do we really need to stoop to this level with coreboot? What is to be gained by hiding the reality of the situation from non-technical users visiting the website? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Am So., 1. Sept. 2019 um 17:30 Uhr schrieb Matt B < matthewwbradley6@gmail.com>:
To take an extreme stance, could non-technical users one day be directed to coreboot distributions like Librecore or vendors like Purism/System76?
Maybe we need to make the visitor segmentation more visible, but I'd expect non-technical users to fit in the "For End Users" bucket. After talking about generic benefits, it points to producers of coreboot-supported hardware (such as Chrome OS and Purism) and to coreboot distros like Libreboot and MrChromebox's.
So that's pretty much what you're proposing, no?
Patrick
Just a note on oreboot: the name is taken, it means Rust, not C, and you can see our talk about it next week. It works on SiFive HiFive-U. We'd love to have help on real ARM chips.
We intend to be forceful about holding the line on "no development from NDA data sheets", "no binary blobs", as well as holding the line on "no C". This also means we don't expect to run on x86 now if ever.
ron
----- Original Message -----
From: "ron minnich" rminnich@gmail.com To: "Patrick Georgi" pgeorgi@google.com Cc: "Matt B" matthewwbradley6@gmail.com, "Timothy Pearson" tpearson@raptorengineering.com, "David Hendricks" david.hendricks@gmail.com, "coreboot" coreboot@coreboot.org Sent: Sunday, September 1, 2019 2:49:42 PM Subject: Re: [coreboot] Re: Web site revamp
Just a note on oreboot: the name is taken, it means Rust, not C, and you can see our talk about it next week. It works on SiFive HiFive-U. We'd love to have help on real ARM chips.
We intend to be forceful about holding the line on "no development from NDA data sheets", "no binary blobs", as well as holding the line on "no C". This also means we don't expect to run on x86 now if ever.
ron
Interesting. That sounds like the kind of project we should be backing. Let me poke around some and see if I can't redirect the current POWER for coreboot effort over to oreboot. :)
Am So., 1. Sept. 2019 um 02:23 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
Another bad analogy: if I start a project for "maximum control" of an airliner, but the reality of the situation is the best level of control I can ever attain is how far back my seat reclines, then the wording is purposefully grandiose, opaque and (IMO) rather weasel-worded to make it sound like the project is doing something far more than it can ever accomplish.
A project for maximum control of an airliner that stops at seat configurations shouldn't talk about maximum control of an airliner.
But coreboot isn't content with all these blobs, so this analogy, no matter how bad or good it is, doesn't apply. Blobs are just the situation we're in that enables us to continue to work on coreboot, push it in the market (and thereby create demand. Even IBVs are now doing coreboot development for hire after years of "if you want to do a project like that you MUST go UEFI") and create channels where we can discuss how to get rid of blobs. Most of this doesn't happen in the open, but that's due to how business works, with NDAs and all that other magic pixie dust that corporate lawyers sprinkle over these companies' engineers' work as if that's good for anything.
coreboot is _aiming_ for nothing less than 100% open. We're just not waiting for that to happen spontaneously (it won't).
Since home-CMOS isn't a very likely prospect (and where they succeed they mostly move the goal post because all those lithography machines still need to come from somewhere), we need to work with silicon vendors somehow to be able to run software. Getting them to put their magic in the chips and documentation for those rather than in their legal agreements seems a more worthwhile cause to me.
People don't want to get into that dirty work? Fine. libreboot can be a good home for them. But they won't change the shape of the industry in a way that renders the blobs question obsolete: Silicon vendors don't have to care about us until it means business. Getting coreboot out there in products is the money-shaped carrot we're dangling in front of them.
10 years ago it would have been entirely impossible for Intel to acknowledge that any part of firmware could be "open" (yes, Tianocore was open source but that was for the IBV consortium that calls itself UEFI Forum, not for the general population to hack on). The fully open i945 port (that is older than 10 years) happened despite Intel, not because of them, and I'm pretty sure that back then the folks in charge there were expecting that to be a one-off. And now they're a big sponsor of and send lots of speakers to the Open Source Firmware Conference.
That's quite a shift in perspective, and it wouldn't have happened without coreboot remaining a constant talking point and thorn in Intel's side. There's one easy way to unroll all of that and that's by stopping to work with them. I don't think that would be a desirable result.
What is to be gained by hiding the reality of the situation from
non-technical users visiting the website?
I suppose we could create an online course on hardware init with some chapters of vendor business models thrown in to provide a full picture, but with anything less than that, no matter what we say, users will be confused. Firmware is simply a rather opaque field (see: the magic capabilities that random people on the internet tend to ascribe to "firmware").
Patrick
----- Original Message -----
From: "Patrick Georgi" pgeorgi@google.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "David Hendricks" david.hendricks@gmail.com, "coreboot" coreboot@coreboot.org Sent: Sunday, September 1, 2019 10:30:30 AM Subject: Re: [coreboot] Re: Web site revamp
Am So., 1. Sept. 2019 um 02:23 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
Another bad analogy: if I start a project for "maximum control" of an airliner, but the reality of the situation is the best level of control I can ever attain is how far back my seat reclines, then the wording is purposefully grandiose, opaque and (IMO) rather weasel-worded to make it sound like the project is doing something far more than it can ever accomplish.
A project for maximum control of an airliner that stops at seat configurations shouldn't talk about maximum control of an airliner.
But coreboot isn't content with all these blobs, so this analogy, no matter how bad or good it is, doesn't apply. Blobs are just the situation we're in that enables us to continue to work on coreboot, push it in the market (and thereby create demand. Even IBVs are now doing coreboot development for hire after years of "if you want to do a project like that you MUST go UEFI") and create channels where we can discuss how to get rid of blobs. Most of this doesn't happen in the open, but that's due to how business works, with NDAs and all that other magic pixie dust that corporate lawyers sprinkle over these companies' engineers' work as if that's good for anything.
coreboot is _aiming_ for nothing less than 100% open. We're just not waiting for that to happen spontaneously (it won't).
Since home-CMOS isn't a very likely prospect (and where they succeed they mostly move the goal post because all those lithography machines still need to come from somewhere), we need to work with silicon vendors somehow to be able to run software. Getting them to put their magic in the chips and documentation for those rather than in their legal agreements seems a more worthwhile cause to me.
People don't want to get into that dirty work? Fine. libreboot can be a good home for them. But they won't change the shape of the industry in a way that renders the blobs question obsolete: Silicon vendors don't have to care about us until it means business. Getting coreboot out there in products is the money-shaped carrot we're dangling in front of them.
10 years ago it would have been entirely impossible for Intel to acknowledge that any part of firmware could be "open" (yes, Tianocore was open source but that was for the IBV consortium that calls itself UEFI Forum, not for the general population to hack on). The fully open i945 port (that is older than 10 years) happened despite Intel, not because of them, and I'm pretty sure that back then the folks in charge there were expecting that to be a one-off. And now they're a big sponsor of and send lots of speakers to the Open Source Firmware Conference.
That's quite a shift in perspective, and it wouldn't have happened without coreboot remaining a constant talking point and thorn in Intel's side. There's one easy way to unroll all of that and that's by stopping to work with them. I don't think that would be a desirable result.
What is to be gained by hiding the reality of the situation from
non-technical users visiting the website?
I suppose we could create an online course on hardware init with some chapters of vendor business models thrown in to provide a full picture, but with anything less than that, no matter what we say, users will be confused. Firmware is simply a rather opaque field (see: the magic capabilities that random people on the internet tend to ascribe to "firmware").
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
This is an interesting take on the situation. Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware (in terms of percentage of vendor firmware binary size to utilized coreboot codebase binary size) for a top-of-the-line platform vs. the older platforms? Is the trend line even going in the right direction?
My outside take on the situation is that coreboot is losing and doesn't even know it yet. The goal you state is unattainable according to public statements from both Intel and AMD, and we have reached the point where people are starting to simply say "the proprietary code is mandatory and unremovable, let's try to reverse engineer it instead to determine if it is safe enough to use since there is no other option". That capitulation means we've lost entirely when measured against the origins and above-stated goals of the coreboot project.
Fundamentally what I see is that that coreboot has morphed into something that is of use to some industry players but has accepted so much binary only firmware in an attempt to still cater to silicon vendors that it is just an open version of Aptio or Insyde. A repeated general philosophy of hoping vendors will open more if coreboot accepts more of their binaries, when the reality in the GIT tree right now, today, is the exact opposite, is seriously concerning and flies in the face of the statements on the Web site.
Again, I ask that the Website be updated to better reflect the distinction between project aspirations with no industry backing and the actual, on the ground reality of the situation, not just today, but over the past several years.
Respectfully,
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com
I should add that I support what Patrick is saying in this discussion. I think he's right.
This is a good question to ask: "Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware ..."
I think I can: I can point to the increasing number of committers from intel.com to coreboot.
I can also point out that every FSP/coreboot system that ships, ships without the many megabytes of UEFI DXEs that are not needed; FSP represents a pretty large blob-ectomy.
More is happening. There will be some interesting announcements this month. I wish developments could be more public, for a number of chipset and board vendors. But I do know for a fact the world is moving in the right direction, although it is agonizingly slow. And such movement is thanks to unceasing efforts of folks like Patrick to make it so.
ron
On Sun, Sep 1, 2019 at 2:55 PM Timothy Pearson tpearson@raptorengineering.com wrote:
----- Original Message -----
From: "Patrick Georgi" pgeorgi@google.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "David Hendricks" david.hendricks@gmail.com, "coreboot" coreboot@coreboot.org Sent: Sunday, September 1, 2019 10:30:30 AM Subject: Re: [coreboot] Re: Web site revamp
Am So., 1. Sept. 2019 um 02:23 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
Another bad analogy: if I start a project for "maximum control" of an airliner, but the reality of the situation is the best level of control I can ever attain is how far back my seat reclines, then the wording is purposefully grandiose, opaque and (IMO) rather weasel-worded to make it sound like the project is doing something far more than it can ever accomplish.
A project for maximum control of an airliner that stops at seat configurations shouldn't talk about maximum control of an airliner.
But coreboot isn't content with all these blobs, so this analogy, no matter how bad or good it is, doesn't apply. Blobs are just the situation we're in that enables us to continue to work on coreboot, push it in the market (and thereby create demand. Even IBVs are now doing coreboot development for hire after years of "if you want to do a project like that you MUST go UEFI") and create channels where we can discuss how to get rid of blobs. Most of this doesn't happen in the open, but that's due to how business works, with NDAs and all that other magic pixie dust that corporate lawyers sprinkle over these companies' engineers' work as if that's good for anything.
coreboot is _aiming_ for nothing less than 100% open. We're just not waiting for that to happen spontaneously (it won't).
Since home-CMOS isn't a very likely prospect (and where they succeed they mostly move the goal post because all those lithography machines still need to come from somewhere), we need to work with silicon vendors somehow to be able to run software. Getting them to put their magic in the chips and documentation for those rather than in their legal agreements seems a more worthwhile cause to me.
People don't want to get into that dirty work? Fine. libreboot can be a good home for them. But they won't change the shape of the industry in a way that renders the blobs question obsolete: Silicon vendors don't have to care about us until it means business. Getting coreboot out there in products is the money-shaped carrot we're dangling in front of them.
10 years ago it would have been entirely impossible for Intel to acknowledge that any part of firmware could be "open" (yes, Tianocore was open source but that was for the IBV consortium that calls itself UEFI Forum, not for the general population to hack on). The fully open i945 port (that is older than 10 years) happened despite Intel, not because of them, and I'm pretty sure that back then the folks in charge there were expecting that to be a one-off. And now they're a big sponsor of and send lots of speakers to the Open Source Firmware Conference.
That's quite a shift in perspective, and it wouldn't have happened without coreboot remaining a constant talking point and thorn in Intel's side. There's one easy way to unroll all of that and that's by stopping to work with them. I don't think that would be a desirable result.
What is to be gained by hiding the reality of the situation from
non-technical users visiting the website?
I suppose we could create an online course on hardware init with some chapters of vendor business models thrown in to provide a full picture, but with anything less than that, no matter what we say, users will be confused. Firmware is simply a rather opaque field (see: the magic capabilities that random people on the internet tend to ascribe to "firmware").
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
This is an interesting take on the situation. Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware (in terms of percentage of vendor firmware binary size to utilized coreboot codebase binary size) for a top-of-the-line platform vs. the older platforms? Is the trend line even going in the right direction?
My outside take on the situation is that coreboot is losing and doesn't even know it yet. The goal you state is unattainable according to public statements from both Intel and AMD, and we have reached the point where people are starting to simply say "the proprietary code is mandatory and unremovable, let's try to reverse engineer it instead to determine if it is safe enough to use since there is no other option". That capitulation means we've lost entirely when measured against the origins and above-stated goals of the coreboot project.
Fundamentally what I see is that that coreboot has morphed into something that is of use to some industry players but has accepted so much binary only firmware in an attempt to still cater to silicon vendors that it is just an open version of Aptio or Insyde. A repeated general philosophy of hoping vendors will open more if coreboot accepts more of their binaries, when the reality in the GIT tree right now, today, is the exact opposite, is seriously concerning and flies in the face of the statements on the Web site.
Again, I ask that the Website be updated to better reflect the distinction between project aspirations with no industry backing and the actual, on the ground reality of the situation, not just today, but over the past several years.
Respectfully,
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Right after sending my note I got a note from a friend:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Hiring-For-Coreb...
"We were tipped off today that AMD's Head of Platform Firmware, Edward Benyukhis, publicly posted on LinkedIn that he is "looking to hire someone with solid Coreboot and UEFI background." If you have Coreboot experience or know someone who is, see LinkedIn for contacting Benyukhis."
I am convinced that things are getting better.
On Sun, Sep 1, 2019 at 7:38 PM ron minnich rminnich@gmail.com wrote:
I should add that I support what Patrick is saying in this discussion. I think he's right.
This is a good question to ask: "Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware ..."
I think I can: I can point to the increasing number of committers from intel.com to coreboot.
I can also point out that every FSP/coreboot system that ships, ships without the many megabytes of UEFI DXEs that are not needed; FSP represents a pretty large blob-ectomy.
More is happening. There will be some interesting announcements this month. I wish developments could be more public, for a number of chipset and board vendors. But I do know for a fact the world is moving in the right direction, although it is agonizingly slow. And such movement is thanks to unceasing efforts of folks like Patrick to make it so.
ron
On Sun, Sep 1, 2019 at 2:55 PM Timothy Pearson tpearson@raptorengineering.com wrote:
----- Original Message -----
From: "Patrick Georgi" pgeorgi@google.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "David Hendricks" david.hendricks@gmail.com, "coreboot" coreboot@coreboot.org Sent: Sunday, September 1, 2019 10:30:30 AM Subject: Re: [coreboot] Re: Web site revamp
Am So., 1. Sept. 2019 um 02:23 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
Another bad analogy: if I start a project for "maximum control" of an airliner, but the reality of the situation is the best level of control I can ever attain is how far back my seat reclines, then the wording is purposefully grandiose, opaque and (IMO) rather weasel-worded to make it sound like the project is doing something far more than it can ever accomplish.
A project for maximum control of an airliner that stops at seat configurations shouldn't talk about maximum control of an airliner.
But coreboot isn't content with all these blobs, so this analogy, no matter how bad or good it is, doesn't apply. Blobs are just the situation we're in that enables us to continue to work on coreboot, push it in the market (and thereby create demand. Even IBVs are now doing coreboot development for hire after years of "if you want to do a project like that you MUST go UEFI") and create channels where we can discuss how to get rid of blobs. Most of this doesn't happen in the open, but that's due to how business works, with NDAs and all that other magic pixie dust that corporate lawyers sprinkle over these companies' engineers' work as if that's good for anything.
coreboot is _aiming_ for nothing less than 100% open. We're just not waiting for that to happen spontaneously (it won't).
Since home-CMOS isn't a very likely prospect (and where they succeed they mostly move the goal post because all those lithography machines still need to come from somewhere), we need to work with silicon vendors somehow to be able to run software. Getting them to put their magic in the chips and documentation for those rather than in their legal agreements seems a more worthwhile cause to me.
People don't want to get into that dirty work? Fine. libreboot can be a good home for them. But they won't change the shape of the industry in a way that renders the blobs question obsolete: Silicon vendors don't have to care about us until it means business. Getting coreboot out there in products is the money-shaped carrot we're dangling in front of them.
10 years ago it would have been entirely impossible for Intel to acknowledge that any part of firmware could be "open" (yes, Tianocore was open source but that was for the IBV consortium that calls itself UEFI Forum, not for the general population to hack on). The fully open i945 port (that is older than 10 years) happened despite Intel, not because of them, and I'm pretty sure that back then the folks in charge there were expecting that to be a one-off. And now they're a big sponsor of and send lots of speakers to the Open Source Firmware Conference.
That's quite a shift in perspective, and it wouldn't have happened without coreboot remaining a constant talking point and thorn in Intel's side. There's one easy way to unroll all of that and that's by stopping to work with them. I don't think that would be a desirable result.
What is to be gained by hiding the reality of the situation from
non-technical users visiting the website?
I suppose we could create an online course on hardware init with some chapters of vendor business models thrown in to provide a full picture, but with anything less than that, no matter what we say, users will be confused. Firmware is simply a rather opaque field (see: the magic capabilities that random people on the internet tend to ascribe to "firmware").
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
This is an interesting take on the situation. Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware (in terms of percentage of vendor firmware binary size to utilized coreboot codebase binary size) for a top-of-the-line platform vs. the older platforms? Is the trend line even going in the right direction?
My outside take on the situation is that coreboot is losing and doesn't even know it yet. The goal you state is unattainable according to public statements from both Intel and AMD, and we have reached the point where people are starting to simply say "the proprietary code is mandatory and unremovable, let's try to reverse engineer it instead to determine if it is safe enough to use since there is no other option". That capitulation means we've lost entirely when measured against the origins and above-stated goals of the coreboot project.
Fundamentally what I see is that that coreboot has morphed into something that is of use to some industry players but has accepted so much binary only firmware in an attempt to still cater to silicon vendors that it is just an open version of Aptio or Insyde. A repeated general philosophy of hoping vendors will open more if coreboot accepts more of their binaries, when the reality in the GIT tree right now, today, is the exact opposite, is seriously concerning and flies in the face of the statements on the Web site.
Again, I ask that the Website be updated to better reflect the distinction between project aspirations with no industry backing and the actual, on the ground reality of the situation, not just today, but over the past several years.
Respectfully,
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Am So., 1. Sept. 2019 um 23:55 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
This is an interesting take on the situation. Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware (in terms of percentage of vendor firmware binary size to utilized coreboot codebase binary size) for a top-of-the-line platform vs. the older platforms? Is the trend line even going in the right direction?
You seem to mix up the temporary wins we had around 2007 (which involved, among other things, pressure put on vendors by what amounts to the CTO of a major industrial nation) with the original state of PC-era firmware. The trendline starts at 0 LOC that are open source.
we have reached the point where people are starting to simply say "the proprietary code is mandatory and unremovable, let's try to reverse engineer it instead to determine if it is safe enough to use since there is no other option". That capitulation means we've lost entirely when measured against the origins and above-stated goals of the coreboot project.
But that's how the project started out!
The early work was grassroots efforts inside mainboard vendors. That hinged on enthusiastic developers at mainboard vendors staying where they are (instead of furthering their careers and leaving their toys behind) and flying under the radar (which pretty much implies "doesn't scale": as soon as that stuff is noticed by silicon vendors, they shut it down through updated contracts).
Later, coreboot was picked up by government IT with high security needs. While you can get pretty powerful people to support you here, it's still only a tiny market. How often can you put pressure on a silicon vendor in that situation before they ask you to shove it? (experience says: not that often)
Where we are now is high volume deployments (Chromebooks on the portable side, Facebook infrastructure on the datacenter end). Again both of these started out at 0 LOC open source less than 10 years ago.
I like our trend lines (although I'd prefer them to be steeper, too).
Again, I ask that the Website be updated to better reflect the distinction between project aspirations with no industry backing and the actual, on the ground reality of the situation, not just today, but over the past several years.
The mission statement of a hunger aid program isn't "feed 500k people", it's "end hunger". "Feed 500k people" is just a milestone.
Patrick
----- Original Message -----
From: "Patrick Georgi" pgeorgi@google.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "David Hendricks" david.hendricks@gmail.com, "coreboot" coreboot@coreboot.org Sent: Monday, September 2, 2019 1:06:10 AM Subject: Re: [coreboot] Re: Web site revamp
Am So., 1. Sept. 2019 um 23:55 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
This is an interesting take on the situation. Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware (in terms of percentage of vendor firmware binary size to utilized coreboot codebase binary size) for a top-of-the-line platform vs. the older platforms? Is the trend line even going in the right direction?
You seem to mix up the temporary wins we had around 2007 (which involved, among other things, pressure put on vendors by what amounts to the CTO of a major industrial nation) with the original state of PC-era firmware. The trendline starts at 0 LOC that are open source.
we have reached the point where people are starting to simply say "the proprietary code is mandatory and unremovable, let's try to reverse engineer it instead to determine if it is safe enough to use since there is no other option". That capitulation means we've lost entirely when measured against the origins and above-stated goals of the coreboot project.
But that's how the project started out!
The early work was grassroots efforts inside mainboard vendors. That hinged on enthusiastic developers at mainboard vendors staying where they are (instead of furthering their careers and leaving their toys behind) and flying under the radar (which pretty much implies "doesn't scale": as soon as that stuff is noticed by silicon vendors, they shut it down through updated contracts).
Later, coreboot was picked up by government IT with high security needs. While you can get pretty powerful people to support you here, it's still only a tiny market. How often can you put pressure on a silicon vendor in that situation before they ask you to shove it? (experience says: not that often)
Where we are now is high volume deployments (Chromebooks on the portable side, Facebook infrastructure on the datacenter end). Again both of these started out at 0 LOC open source less than 10 years ago.
I like our trend lines (although I'd prefer them to be steeper, too).
I do understand, but at the time in 2007 crypto locking of anything was still pretty rare. Not that long before the fact that the TiVo was locked literally made headlines. We're now in a position where there are large, and growing, parts of the firmware that are simply off limits to this type of approach, and somehow we're not drawing a distinction between "can be replaced without vendor permission" and "vendor absolutely must go against its already stated goals to allow us to replace this part". I think we need to step back and have some serious discussion around that before we can really determine if the current approach is working.
Unless I'm mistaken, the firmware parts that have open source coreboot code in them now are *not* the parts that are locked behind the signing keys. It feels like we're sorta kinda maintaining status quo (maybe with a bit of vendor help now) for the unlocked parts, while completely ignoring the losses to the new signed/locked parts.
Again, I ask that the Website be updated to better reflect the distinction between project aspirations with no industry backing and the actual, on the ground reality of the situation, not just today, but over the past several years.
The mission statement of a hunger aid program isn't "feed 500k people", it's "end hunger". "Feed 500k people" is just a milestone.
You have something here...the Web site doesn't read like an unattainable (but admirable) goal. It reads like this is where we are today. When anyone says "end world hunger" they immediately understand just how impossible that really is, but understand as well it's an aspiration worthy of working toward. Coreboot on x86 doesn't have that kind of immediate recognition of the unattainable nature of the goal, and that is directly harming other architectures, systems, and projects where the goal is already attained today.
What about following proposal: coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it aims to provide auditability and maximum control over technology; On some platforms (especially non-open ISA platforms), some boot functionalities are provided by Silicon Vendor binary blobs.
This is too wordy and full of jargon, and confuses goals.
it was never about the speed. The speed was a nice side effect, but ti was really about the openness. Once you start talking about speed you lose the thread -- we had this problem all the time in 2000: vendors got focused on fast and missed the main point, that we wanted control.
Remember that many people come to coreboot thinking they're going to load a usb stick up and install it somehow. Few people have any clue what's going on here.
You need fewer adjectives, and simpler words.
ron
----- Original Message -----
From: "ron minnich" rminnich@gmail.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "Patrick Georgi" pgeorgi@google.com, "David Hendricks" david.hendricks@gmail.com, "coreboot" coreboot@coreboot.org Sent: Monday, September 2, 2019 2:56:21 AM Subject: Re: [coreboot] Re: Web site revamp
What about following proposal: coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it aims to provide auditability and maximum control over technology; On some platforms (especially non-open ISA platforms), some boot functionalities are provided by Silicon Vendor binary blobs.
This is too wordy and full of jargon, and confuses goals.
it was never about the speed. The speed was a nice side effect, but ti was really about the openness. Once you start talking about speed you lose the thread -- we had this problem all the time in 2000: vendors got focused on fast and missed the main point, that we wanted control.
Remember that many people come to coreboot thinking they're going to load a usb stick up and install it somehow. Few people have any clue what's going on here.
You need fewer adjectives, and simpler words.
ron
Apologies, but I'm a bit confused -- just a bit earlier it sounded like the open / control aspects were now secondary to market share and vendor contribution concerns. Did I pick up the wrong impression?
If coreboot is indeed supposed to be focusing on those two attributes, this text needs to be completely rewritten to clearly show where the limits are on modern x86 platforms. No more molly-coddling the ME/PSP, it needs to be very clear where coreboot is locked out by vendor dictate and (as a result) what coreboot cannot fix without a change of direction from the silicon vendors.
"coreboot is an open firmware platform with its primary goal as a fully owner controlled, secure boot experience. For open ISA and other owner controlled systems, it currently provides an auditable, secure boot environment for silicon vendors, large organizations, and individual developers. For restricted systems, such as modern x86 platforms, it provides a compatible end stage loader and firmware module framework for proprietary vendor binaries.".
This might be a bit strongly worded, but you can see where I'm trying to go with it?
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com
Am Mo., 2. Sept. 2019 um 10:17 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
this text needs to be completely rewritten to clearly show where the limits are on modern x86 platforms.
No, you want it rewritten to be able to better advertise Talos. This project is not in the business of advertising your project, even though we do (It's mentioned in the distributions list despite there being no coreboot port for it yet).
(as a result) what coreboot cannot fix without a change of direction from the silicon vendors.
You're promoting a system that comes with native NVLink support. Where's the nvidia GPU that runs with unsigned firmware? Get off your high horse, it limps.
Patrick
----- Original Message -----
From: "Patrick Georgi" pgeorgi@google.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "ron minnich" rminnich@gmail.com, "David Hendricks" david.hendricks@gmail.com, "coreboot" coreboot@coreboot.org Sent: Monday, September 2, 2019 3:26:45 AM Subject: Re: [coreboot] Re: Web site revamp
Am Mo., 2. Sept. 2019 um 10:17 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
this text needs to be completely rewritten to clearly show where the limits are on modern x86 platforms.
No, you want it rewritten to be able to better advertise Talos. This project is not in the business of advertising your project, even though we do (It's mentioned in the distributions list despite there being no coreboot port for it yet).
No, that's not what I want at all. Don't conflate the honest desire to deal with what I consider a significant issue on the x86 side with something else. Please do note that nowhere did I say Talos, in fact I specifically indicated several systems with open ISA and owner controlled CPUs (RISC-V, MIPS, and yes POWER). *Any* of these actually meet the goal of an owner controlled, open source boot right here and now, versus hoping one of the x86 vendors will release ME/PSP unlocked CPUs. I'd be quite happy if even one of the RISC-V boards (that Raptor doesn't make) was the poster child for coreboot at this point -- anything other than the signed binary situation we have now with x86.
(as a result) what coreboot cannot fix without a change of direction from the silicon vendors.
You're promoting a system that comes with native NVLink support. Where's the nvidia GPU that runs with unsigned firmware? Get off your high horse, it limps.
I think this is the point where rational discussion has stopped and personal attacks have started, so I'll take a break and see where things go in my absence. Just for the record, we don't (and never have) promoted NVLink, our systems don't have the required firmware binaries installed to make it work, *and* we preferentially promote and ship open driver AMD GPUs. We even waited to introduce CAPI until OpenCAPI with its open firmware was available. The only thing I see limping here is the x86 horse, hobbled by its signed, proprietary, black box coprocessors and NDA-restricted documentation.
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com
Dear Timothy,
On 9/2/19 10:17 AM, Timothy Pearson wrote:
----- Original Message -----
Sent: Monday, September 2, 2019 2:56:21 AM
What about following proposal: coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it aims to provide auditability and maximum control over technology; On some platforms (especially non-open ISA platforms), some boot functionalities are provided by Silicon Vendor binary blobs.
This is too wordy and full of jargon, and confuses goals.
it was never about the speed. The speed was a nice side effect, but ti was really about the openness. Once you start talking about speed you lose the thread -- we had this problem all the time in 2000: vendors got focused on fast and missed the main point, that we wanted control.
Remember that many people come to coreboot thinking they're going to load a usb stick up and install it somehow. Few people have any clue what's going on here.
You need fewer adjectives, and simpler words.
Apologies, but I'm a bit confused -- just a bit earlier it sounded like the open / control aspects were now secondary to market share and vendor contribution concerns. Did I pick up the wrong impression?
Ron, “lightning fast” is mentioned in the current text on the Web site already.
If coreboot is indeed supposed to be focusing on those two attributes, this text needs to be completely rewritten to clearly show where the limits are on modern x86 platforms. No more molly-coddling the ME/PSP, it needs to be very clear where coreboot is locked out by vendor dictate and (as a result) what coreboot cannot fix without a change of direction from the silicon vendors.
"coreboot is an open firmware platform with its primary goal as a fully owner controlled, secure boot experience. For open ISA and other owner controlled systems, it currently provides an auditable, secure boot environment for silicon vendors, large organizations, and individual developers. For restricted systems, such as modern x86 platforms, it provides a compatible end stage loader and firmware module framework for proprietary vendor binaries.".
This might be a bit strongly worded, but you can see where I'm trying to go with it?
Basically, I agree with Timothy on the problem and the user confusion. Puri.sm basically omits the FSP in all their blog posts, and the user gets the impression, that the whole firmware is free software [1].
I think, we can work on improving the text, and it’s great that Patrick posted proposals.
I believe, we should a agree on a few thinks first though.
1. I do not think, that the openness of the ISA plays any role for coreboot, so it does not need to be mentioned on the main page, and should be moved.
2. Should the Intel ME and PSP be seen as independent devices like the embedded controller? In my opinion it should be, and therefore, also does not need to be mentioned on the main page. (Unless somebody comes up with a succinct wording.)
3. So, that leaves FSP and AMD Binary PI for x86 (and other blobs for ARM). I believe, this should be mentioned in some way.
If you agree, I propose the text below, where *Open Source* is moved to the beginning, and *framework* added in the end.
coreboot is an extended Open Source firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. The project aims to provide auditability and maximum control over technology. But, the framework also allows to include binary blobs to initialize certain devices.
Maybe some native speaker finds better wording.
Kind regards,
Paul
Hi all.
On Mon, 2 Sep 2019 11:13:42 +0200 Paul Menzel pmenzel@molgen.mpg.de wrote: [...]
Basically, I agree with Timothy on the problem and the user confusion. Puri.sm basically omits the FSP in all their blog posts, and the user gets the impression, that the whole firmware is free software [1].
I too agree with Timothy for the most part. I regularly (albeit not very often) speak to people who have learned about coreboot and say that they want to flash their computer, mostly laptops, and are surprised when I tell them that it's not as open source as they think, i.e. vendor-provided binary blobs are necessary to boot their x86 platform.
But, I don't think a split of the project would be beneficial here. There are eoungh project splits already in the open source world, and I'm sure coreboot at its heart still aims for a 100% open source boot experience.
But maybe coreboot could improve in educating new end users about the current status regarding blobs required for platform bring-up.
What about a new headline "Current blob status" on the "End Users" page? https://www.coreboot.org/users.html
I think, we can work on improving the text, and it’s great that Patrick posted proposals.
I believe, we should a agree on a few thinks first though.
- I do not think, that the openness of the ISA plays any role for coreboot, so it does not need to be mentioned on the main page, and should be moved.
I second that.
- Should the Intel ME and PSP be seen as independent devices like the embedded controller? In my opinion it should be, and therefore, also does not need to be mentioned on the main page. (Unless somebody comes up with a succinct wording.)
I also don't think mentioning the ME, PSP et al on the main page is a good idea, since they are architecture specific co-processors.
But I don't think they should be considered completely independent devices anymore, since they have become more and more involved in platform bring-up over the last years, and well, coreboot is about exactly that: https://doc.coreboot.org/#purpose-of-coreboot
It would be interesting to hear what the current core developers and maintainers of coreboot think about the status of these co-processors, and how much they fall into the scope of the coreboot project.
Maybe some native speaker finds better wording.
I'm not a native speaker, but I want to share my two cents here...
The current text reads as follows:
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
Idea 1) In the first sentence, instead of "coreboot is an extended firmware platform that delivers" write one of the following: "coreboot is an extended firmware platform that aims to provide" "coreboot is an extended firmware platform that strives to provide" "coreboot is an extended firmware platform with the goal to provide" ... and then make the changed text (e.g. "that aims to provide") a link to a page that describes the current blob situation, or to a new section of the "End Users" page like I proposed above.
Idea 2) Leave the text as is and add a new simple one-line paragraph below it, which could read like
"You can [read here] about the current open source status of coreboot." or "You can [read here] about the current use of blobs in coreboot." or something similar, again, linking to a place which explains the current use of blobs in coreboot.
In any case, IMO it would be nice to keep it rather short and succinct as it is now, and not bloat it up too much.
Cheers,
Merlin
- Should the Intel ME and PSP be seen as independent devices like the embedded controller? In my opinion it should be, and therefore, also does not need to be mentioned on the main page.
If that is the case (and I do agree, ME's feature-set has been more extensive and invasive than merely platform bring-up for some time), shouldn't users be made aware of it sooner?
I think that considering the objective of a blob could help towards classifying it. In the past, didn't coreboot say that FSP aligned with its goals (if not, I read it somewhere else)? In contrast, ME implements a DRM.
In the past, didn't coreboot say that FSP aligned with its goals
Not that it shouldn't still be open-sourced anyway.
Am Mo., 2. Sept. 2019 um 09:56 Uhr schrieb ron minnich rminnich@gmail.com:
You need fewer adjectives, and simpler words.
Maybe we can get there with less bikeshedding by looking at concrete proposals:
https://review.coreboot.org/c/homepage/+/35209 and https://review.coreboot.org/c/homepage/+/35210 (and more later).
Patrick
Hi,
I believe we have consensus that the current wording as-is may be misleading to some audiences:
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
The proposal of "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology.", however, does not reflect the project's goal and architecture.
Coreboot community (and its leadership) has been taking a (rightfully) pragmatic approach, which moves the industry to the right direction. Even though the pace is not as fast as many would wish, evidences show the current strategy is the best we could have.
What about following proposal: coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it aims to provide auditability and maximum control over technology; On some platforms (especially non-open ISA platforms), some boot functionalities are provided by Silicon Vendor binary blobs.
Thanks, Jonathan
On Sat, Aug 31, 2019 at 2:54 PM Timothy Pearson tpearson@raptorengineering.com wrote:
I'd like to open discussion on a revamp of the text on the main coreboot.org Web site. I had a brief discussion on IRC recently with some basic agreement from a couple of people that the text on that page has likely bitrotted enough compared to the current status and goals of coreboot to no longer be useful.
I bring this up due to confusion in less technical circles that I've been having to correct over the past week or so. Specifically, these statements taken in isolation:
"Fast, secure and flexible OpenSource firmware"
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
present a very different picture than the reality of the project at the moment for modern platforms. If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements above at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware. As those of us dealing with the reality of modern x86 and ARM platforms understand more fully, this could not be farther from the truth.
One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One is the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for vendor binaries, which is not well understood at this time among much of the open source community, but seems to have significant support from vendors like Google, Intel, and AMD.
Complicating matters, the trademark "coreboot" is currently known to some members of the public as a trusted (albeit limited in compatibility) fully open source replacement for their exiting board level firmware. When the word "coreboot" is used, very few people think of the glue project. Do we want to dilute / shift the coreboot trademark / branding to the glue part of the project, or do we want to somehow reserve "coreboot" for the native init part of the project? I don't have an answer here, I'm just trying to state the facts as I currently see them for further discussion.
I would propose the following changes, and welcome discussion on these topics:
The heading could read something like "Flexible, open source frameworks for system firmware"
and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology."
Thoughts?
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
----- Original Message -----
From: "Jonathan Zhang" jon.zhixiong.zhang@gmail.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "coreboot" coreboot@coreboot.org Sent: Monday, September 2, 2019 12:06:54 AM Subject: Re: [coreboot] Web site revamp
Hi,
I believe we have consensus that the current wording as-is may be misleading to some audiences:
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
The proposal of "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology.", however, does not reflect the project's goal and architecture.
Coreboot community (and its leadership) has been taking a (rightfully) pragmatic approach, which moves the industry to the right direction. Even though the pace is not as fast as many would wish, evidences show the current strategy is the best we could have.
What about following proposal: coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it aims to provide auditability and maximum control over technology; On some platforms (especially non-open ISA platforms), some boot functionalities are provided by Silicon Vendor binary blobs.
Thanks, Jonathan
I think it's far clearer than where we are today, and represents a step in the right direction for the public site. Perhaps even clearer would be to replace "especially" with "primarily" and "non-open ISA" with "proprietary ISA"? Just a thought.
Regarding the AMD coreboot position, I am aware of it and have been for some time. I am also aware that AMD requires a PSP binary and has shown no actions toward removing that hard requirement, in fact moving more and more platform initialization into the signed PSP binary. This is my main contention -- EFI aside, what action has actually been taken by silicon vendors to reduce the amount of binary only and vendor-signed code required to execute from first system power on to the coreboot payload stage (i.e. where EFI, Linux, or GRUB tends to take over)? A quick glance through the tree is showing FSP practically everywhere for non-ancient Intel boards, so the number of Intel contributors is not exactly a relevant statistic -- of course Intel has interest in keeping its FSP working if that's all it needs to do to stop reverse engineering and replacement of the FSP / MRC code. And that's not even going into the ME problems.
EFI was never the concern, I apologize if somehow that was not clear. My understanding was that LinuxBIOS was dealing quite well with the EFI objection alone. I understand pragmatism but I don't share the optimism here -- what I see directly (and some of this is also due to visibility into non-public items I likewise can't share) is that the vendor takeaway has been quite simple: move all the platform init away from what people traditionally call the EFI/BIOS, lock it behind a vendor signature, and then you can offer coreboot (or indeed any "payload" type firmware) support without ever running the risk of revealing any sensitive IP. This of course only works because lower level systems like the ME and PSP appear to be largely kept outside of coreboot's firmware model for, I presume, pragmatic reasons, and therefore no one from the public or even from the firmware development side questions the magic that happens to bring the system into a running state with DRAM trained and verified boot already well into its measurement sequence.
I keep bringing this up because I consider it a tragic loss for coreboot to be reduced to a mere loader or late stage device / ACPI setup role. I see nothing obvious in tree right now that contradicts this opinion, except for the rare cases where the larger community reverse engineered and re-implemented support for older Intel and AMD systems, and where those systems still have to run the ME/PSP binaries even at that level unless they are nearly a decade old or more.
I welcome any improvements in the actual owner control situation, I simply do not trust Intel and AMD to adapt to service that requirement given past history and current smokescreen attempts surrounding the PSP in particular. Until I can literally compile my own PSP firmware, modify it, inspect it, load it, run it on real production hardware, etc. those systems represent a massive step backward from where we were even 7 years ago, with no statements from Intel or AMD that they will ever agree to unwinding that level of control at any point (in fact public statements have been made from both that state the exact opposite).
I can download the complete firmware code from the very first instructions through the late stage loader on RISC-V and POWER systems. I can change that code, I can make a minimal firmware that truly fulfills the goals listed on the coreboot site if I want to, then run it on real production hardware. Why should that progress be hidden away in the (IMO vain) hope that the two x86 vendors will at some point embrace the same level of openness and owner control that we have *right here and right now* on so many other platforms?
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com
-
benjamin.doron00＠gmail.com -
David Hendricks -
Dullfire -
Jonathan Zhang -
Matt B -
Merlin Büge -
Patrick Georgi -
Paul Menzel -
ron minnich -
Timothy Pearson