[coreboot] Proposal: "Freedom level" field for boards supported by coreboot

[Julius Werner]

> The only reason for the Bronze classification is the GPU firmware /
> driver.  I'll admit I'm not as familiar with the RK3822 GPU as I'd like,
> so if I made an error and it operates without binary blobs then the C201
> would be reclassified Platinum.  You can't exactly stick a third-party
> GPU on that SoC to get around the built-in GPU, so if it's not free it's
> a major problem.

Fair enough. I didn't count the GPU driver because your defintions
only say "firmware", and I wouldn't call it that (it's a normal kernel
driver, just not open source). If we're getting into normal driver
support things start getting more complicated (e.g. would you count an
Nvidia graphics card as "free"? There is Nouveau, but it's generally
not considered as fast/stable/complete as Nvidia's proprietary
drivers).

I think it's fair to penalize boards for this, but not as hard as for
other components. The machine is still perfectly useable with text
mode or software rendering. I would say this is way less severe than a
non-free EC (which essentially means you can't trust your keyboard),
for example. It should rank somewhere among the low inconveniences,
maybe similar to a non-free WiFi chip.

> I am trying to head off the easiest thing possible for the manufacturer
> - -- that is, produce a board that has one feature set for Windows, and
> another very limited feature set for libre software.  I don't think the
> rankings should be able to be gamed in that manner; when a consumer buys
> a board they expect that the advertised features of that board work, and
> without proprietary software so if we've listed it as Gold or Platinum.

I highly doubt that anyone would bother shipping a whole extra SKU
solely to look good to libre enthusiasts, to be honest. The cost for
that is not trivial.

Anyway, I guess it's fair to rate what's on the board. But the ratings
should take into account the importance of the component, like I tried
to outline with the list below (e.g. how necessary is it to make the
machine usable, and what options does the user have to avoid the
proprietary parts).

> Why are you assuming the internal ROM microcode is safe?  I certainly
> wouldn't go there; in fact, the errata sheets for most processors show
> the exact opposite.

I'm not... but getting into that opens another theoretical can of
worms that I don't think you can really fairly assess. As long as you
don't have the full hardware sources for the CPU, there is no
externally visible difference between a "perfectly free" CPU and one
that contains ROM microcode... you can never know if the vendor didn't
put a backdoor right in the hardware (or if a chip that you think is
decoding instructions directly is actually using non-updateable
microcode). So I think if you want to take microcode into account, the
choice to reject later updates is really the only one the user has.

> I make a very limited exception for an EC that is only an EC; that is,
> it has no ability to transmit any information it gleans to a third
> party.  I'd like to see that exception disappear ASAP, but I think we
> should wait until the free EC implementation for the Lenovo machines is
> finished so that we at least have some examples of true Silver class
> machines.

Maybe. But it means that any temporary exploit at a later time
(including running a firmware update tool for your proprietary EC or
something like that) could expose anything you ever typed. It also
means that you can't convert your machine from a trusted to and
untrusted OS anymore by just wiping everything... you never know what
the EC has still tucked away somewhere (assuming it has flash, which I
think most do). Why not focus on the boards with free ECs we have
already?

>> A. Everything free.
>> B. Non-essential component (e.g. GPS sensor) requiring proprietary firmware.
>> C. Network component (e.g. WiFi) requiring proprietary firmware if it
>> can be bypassed (e.g. USB, expansion card).
>> D. Input/output-sniffing component (pointing device, keyboard,
>> display, audio) requiring proprietary firmware if it can be bypassed,
>> or CPU requiring microcode if it can be bypassed (e.g. just using
>> factory ROM code).
>> E. CPU or equivalently privileged processor requiring non-resident
>> proprietary boot firmware.
>> F. Network component requiring proprietary firmware that cannot be
>> bypassed (e.g. no USB ports).
>> G. Input/output-sniffing component requiring proprietary firmware that
>> cannot be bypassed, or CPU requiring microcode that cannot be
>> bypassed.
>> H. CPU or equivalently privileged processor requiring resident
>> proprietary firmware (e.g. Intel ME, Qualcomm TrustZone).
>
> My concern is mainly the number of levels.  If we make this too much of
> a smooth gradient type thing people won't really understand just how bad
> G and H really are.

Okay, sure... colors or naming could make that more clear, or just
squash some of these categories together. I didn't really want to
exemplify the granularity here, just how I think different non-free
components should be weighted against each other to fairly represent
the risk to the user.

We could also try a system of points that get added together to reach
a certain category (e.g. proprietary microcode is worth 5 malus
points, proprietary WiFi could be 2, and resident proprietary firmware
with full access short-circuits to the lowest category).