[coreboot] [PATCH] disabling microcode update

[xdrudis]

On Mon, Feb 21, 2011 at 08:44:35AM -0600, Scott Duplichan wrote:
> 
> This really isn't relevant, but microcode patch source code
> certainly exists, as does source code for the main microcode
> that the patch modifies. A microcode assembler converts the
> source code into binary form.
>

I think it's relevant. In any case, thank you for the information.
 
> Think about what it would take for public microcode patch source
> code to be useful. First, the processor vendor would have to 
> publish the thousands of lines of source code for the microcode
> that will be patched. Next, the microcode assembler and related
> tools would have to be published. At that point, a lot of training
> is needed to even understand the microcode. Microcode is not
> written in any standard programming language. The language is 
> completely different for different processor vendors, and even for
> different processor models in some cases. Anyway, assume that
> somehow a non-employee became a microcode expert for a particular
> processor model. Why would the patch need to be modified? The
> patch corrects a processor erratum. To modify microcode in a way
> that works around a processor erratum usually requires details of
> the processor design that are not published.
>

Yes, I know the processor is not open hardware. 
Yet, the issue does not vanish just because of this.

You say it would require an expert. Well, that's what average people
think of free software, it takes an expert to modify a program, so who
needs software freedom. I won't untangle that fallacy here to avoid
preaching to the choir.  Sure, there may be more experts apt at
modifying emacs than certain microcode source, but so what? Before I
knew coreboot I didn't think the expertise necessary to write firmware
could be had in a free software project, and now I'm arguing with one
of those experts I thought didn't exist.

There are several free software projects that work around or reverse
engineer secret designs. The fact that it is unlikely or difficult is
no excuse to use other people's work against the license they have
choosen. It's not me you have to convince or you I have to convince,
it's any copyright holder to code linked to this microcode if we
want to make a derivative work.
 
> When a processor is purchased, its source code is not provided. The
> microcode patch is a modification of the processor design, so it is
> not surprising the source code is not supplied.
>

That's a particular point of view, seeing microcode patches as some
kind of binary soldering iron of sorts. I don't see it like that. 
Changing microcode does not change the microprocessor design any more
than changing documentation or firmware. The circuits are so that 
given some microcode perfom some function. They'd do something else
with a different microcode but they would still be the same circuits.
Otherwise any software would be a circuit metamorphoser.

I see microcode as a preloaded propietary program for a VLIW processor
whose purpose is to emulate a CISC processor that happens to have more
application software available.  The x86, amd64 or whatever
instruction set works just like an ABI, similar to parrot or java
bytecodes allowing people to write once and run anywhere, and makes
economic sense. But it does not change the nature of the VLIW
processor.

The processor design is information, VHDL programs if you like. The
only thing that distinguishes the logic that goes to silicon from what
goes to software is the possibility to change it without building
another device. Therefore, microcode is software for a (nondocumented)
machine as soon as it can be modified. This VLIW nondocumented machine
could have compilers for any language that generate microcode or
interpreters for other instruction sets, and maybe I could have the
compiler generate a new opcode to optimize a tight loop or run ARM or
PPC binaries in my Phenom. Not that I'm interested, I'd rather
recompile free software for amd64. And not that it would be economic
to build such a compiler backend for such a small number of CPUs out there.

All this is not trying to bash any cpu vendor or imply any wrongdoing
by anyone. When I bought my CPU it was advertised as amd64, x86 , MMX
, etc.  compatible, not as a VLIW processor I could reprogram by
microcode patches. And I'm not claiming I have a great business model
for paying the engineers and factories to build open hardware of
similar power (although if someone does, I'd like to get some
advertising). And I'm not saying that I'm surprised to know that
sources or documentation for microcode or cpu designs are not
published. I'm just surprised to find microcode linked into GPL
binaries. My intent is just to explain that those wanting these binary
parts left out of their coreboot image are not some kind of luddite
zealots, simply people that like to apply uniform criteria to their
free software.
 
And this is just too much for a rationale for a 69 lines patch,
so I'll leave it here and sorry for the noise.