[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: If Debian support OS certification?

On Wed, May 17, 2017 at 6:34 AM, Thomas Goirand wrote:

> I wonder what you call "everything". In the majority of the servers on
> which I have installed Debian, no non-free firmware were required.

That would be surprising to me, I imagine every one of those servers
was running non-free pre-installed firmware in multiple parts of the
machine. At minimum, every modern platform has a non-free boot ROM
(the first code run by the CPU, physically read-only, may do signature
checking). Then there are CPU microcode, Intel ME/AMD PSP, BIOS/UEFI,
BMC/IPMI/iLO/etc, hard drive or SSD firmware, NIC firmware, screen
firmware, keyboard firmware and so on.

I think what you meant to say was that the majority of the servers you
have run Debian on do not require loading externally supplied non-free
firmware before they will work normally.

I agree that as a practical measure, that is the certification target
that is most useful to end users and most appropriate for Debian right
now, at least until RISC-V/lowRISC hardware becomes widespread.

That said, from the things that the Debian Intel microcode package
maintainer says about microcode bugs on IRC, I'm not sure that it is a
good idea to recommend users run Debian systems without the updates to
the non-free CPU microcode provided by Debian.

>From a Software Freedom PoV though, "do not require loading externally
supplied non-free firmware" may be worse, since pre-installed firmware
is the elephant in the room (hello Intel AMT security bugs). It also
makes reverse engineering harder since pre-installed firmware is
harder to extract. Often there are zero mechanisms (or completely
proprietary ones) to update pre-installed firmware, which complicates
the reverse engineering process significantly and or prevents it for
all but the most sophisticated reverse engineers, for example to those
who can glitch signature checking code by altering power levels.

Only certifying hardware that does not require loading externally
supplied non-free firmware just *incentivises* vendors to just
pre-install their non-free firmware, which has the potential to
slightly reduce Software Freedom around firmware long-term.
So, I'd like us to counteract these incentives by encouraging hardware
vendors to support coreboot and other libre firmware projects and
exposing information to users and vendors about what proprietary
pre-installed software/firmware is present and how it could be

> In my view, a certification Debian logo means we fully endorse.

For Debian I expect your proposal "do not require loading externally
supplied non-free firmware" is something that most of Debian can agree
is a reasonable endorsement target for now. We probably would require
a GR to make a decision about the target though. The FSF RYF
endorsement is approximately what you suggest:


> I do believe a vast majority of the Debian community do not fully
> endorse the requirement of non-free blobs.

I'm not sure that is the case, there appears to be significant support
for including NIC/WiFi firmware in the primary ISO that people
download from the Debian website (or also linking to the non-free ISO
from the front page), because the lack of it means it is harder to
install Debian on modern hardware. There also appears to be support
for installing CPU firmware by default.

> A certification is different from a compatibility checklist.
> Let's not confuse the 2.

Good point, I'd certainly made that mistake up till now.

> Otherwise, we'll have to display different types of logo, like "works
> with Debian ... but", and then that starts to confuse users, which is
> counter-productive.

I think for hardware that doesn't support whatever criteria we come up
with, we just wouldn't have a certification logo but would say "this
hardware is *not* Debian certified because ..., but can run Debian if
...". For "certified" hardware we would include the logo and say "this
hardware is Debian certified, but you need to be aware of these
proprietary components and what their capabilities are".



Reply to: