Re: Eliminating closed source?

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> How hard is it to build a kernel without including any closed-source
>> components?  (For example, most of dev/microcode/, and of course
>> anything depending on it, would have to go.)
> Are you going to stop using all the devices in your system which
> carry their closed-source microcode in ROM, too?

Now, now, you're jumping to conclusions.  (The conclusion in this case
is that avoiding closed source anywhere in my systems is a primary
goal.)

> (I'm not trying to be sarcastic, I'm genuinely curious.  This seems
> profoundly impractical to me -- even modern Ethernet controllers have
> come full-circle to the early days and are microcoded again.)

You're jumping to conclusions again.  (This time, that I'm interested
in systems using "modern", whatever that means, hardware.)

As it happens, the each conclusion is about half right.  (I also notice
you didn't answer the question, though of course I can't tell whether
that's because you don't know the answer, didn't want to answer it,
forgot to mention it when composing your mail, or what.)

I got onto this by looking at kernel size.  On i386 (the only
architecture I have 4.0.1 running on), a 4.0.1 kernel was something
like 24% larger than a 3.1.  I went looking to see why, and the thing
that stood out most was the binary blobs.  (Looking at it yourself you
likely won't see quite that large a difference; the 3.1 kernel I was
comparing against already had a minor effort in that direction done, in
that it has ath support stripped out - athhal.o is the fourth-biggest
file for either text or data size in my 4.0.1 build directory.)

It's true that I would _prefer_ to strip out all closed source.
However, closed-source microcode in ROM bothers me less than
closed-source microcode blobs in the kernel - and a _lot_ less than
closed-source code actually running in the kernel like the ath HAL.

Closed-source microcode that can be rewritten by software (eg,
reflashable BIOS, downloadable disk microcode, etc) is actually the
kind that bothers me most: it means that once cracked the entire
machine is fairly permanently untrustworthy.  I very strongly believe
that any device with such capability needs a hardware - as in, not
overridable by the CPU - way to disable writes.  (Fine, ship with it
write-enabled if you must.  But at least make it possible for people
who care about security to get some minimal modicum of it.)  All the
microcode is of course thoroughly undocumented, but, as history has
shown over and over again, that hurts only the people honest and/or
law-abiding enough to pay attention to things like "no reverse
engineering" distribution terms.

While that is probably a lost cause, at least until some malware takes
advantage of that capability and thus raises awareness of the risk, I
do like to avoid such idiocy where I can.  Especially if it means I can
shrink my kernels substantially in the process.

As for the "modern" hardware, I don't have anything really very modern.
The most modern machines I have are hardware other people are throwing
out because it's so old.  However, the path of good intentions sketched
above is old enough that some of the hardware I do have suffers.        

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B