Re: Possible draft non-free firmware option with SC change
On Mon, 12 Sep 2022 at 19:20:29 +0200, Simon Josefsson wrote:
> Steve McIntyre <steve@einval.com> writes:
> > Many common laptops in the last 5-10 years don't come with wired
> > ethernet; it's becoming rarer over time. They ~all need firmware
> > loading to get onto the network with wifi. Many now need firmware for
> > working non-basic video, and audio also needs firmware on some of the
> > very latest models. The world has changed here, and I think your
> > perceptions may be out of date.
>
> I recall that it took ~5 years until hardware (usually audio, video,
> network cards) was well supported with stable releases of free software
> distributions in the 1990's.
I don't think this is the same thing at all. In the 1990s, it took that
length of time to get Free drivers that run on the main CPU, communicating
with firmware that the devices already had on-board (in ROM or flash) - but
it was usually unnecessary for the OS/driver vendor (in our case Debian)
to supply the device's firmware, because that was already on-board in
permanent storage, updated rarely or not at all.
In the 2020s, independent of how quickly or slowly we get Free drivers
that run on the main CPU, it's often the case that those Free drivers
will need to know how to upload firmware that will run on the device
itself into the device's RAM, and the OS/driver vendor is expected to
supply that firmware, because the device simply does not have permanent
storage on-board where it could keep its firmware any more - at power-on,
all it knows how to do is accept a firmware upload, and it doesn't know
how to play audio or join a network or whatever is its real job until
that firmware arrives.
This design isn't really any less Free than what you had in the 1990s:
in both cases, if you're using a Free OS and Free drivers, you get
total control over what's running on the main-CPU side of the bus, and
no control over what's running on the peripheral device side of the bus
(other than to the extent that it can be controlled by requests sent
by the Free driver). However, the presence of non-Free firmware is a
lot more visible now, because the hardware manufacturer now expects the
OS/driver vendor to be involved in providing it to the hardware.
For devices that *do* still have on-board storage (notably those that
need to start up before the OS kernel), often there is a version of
the non-Free firmware in permanent storage, which is enough to make the
device basically work, but is likely to contain bugs or even security
vulnerabilities (because firmware is software written by fallible humans,
and therefore has bugs). In these cases, being able to upgrade it to a
newer non-Free firmware blob is obviously less desirable than having a
Free replacement, but it's better than being stuck with the version that
originally shipped on your device, and doesn't really give you any less
freedom than if you were stuck with the original version.
In some ways the new situation is better for people who want to
reverse-engineer device firmware - the proprietary firmware blob is right
there for you to look at (rather than being hidden away), and if the
device isn't checking a signature, modifying the Free driver to upload
your replacement firmware blob into the device's RAM is going to be a
lot simpler than reflashing the device using some out-of-band mechanism.
I think you mentioned elsewhere in the thread that you're using a Lenovo
X200? If that's the case, then I'm sorry to inform you that you're
relying on a non-free BIOS (unless you replaced it with Coreboot, which
most of our users are not going to be willing or able to do), non-free
embedded-controller firmware (for the keyboard and battery charging,
among other things), a CPU with non-free microcode, and probably a bunch
of miscellaneous ROMs in things like audio hardware. They might never
have gone through Debian's web servers, and you might never have upgraded
them, but they're there (and you probably *should* upgrade some of them,
particularly the BIOS and the CPU microcode, because otherwise there
are likely to be unfixed security vulnerabilities).
smcv
Reply to: