[coreboot] [PATCH] disabling microcode update

[xdrudis]

On Sat, Feb 26, 2011 at 11:22:17PM +0200, Alex G. wrote:

> I look at the microcode as simply DIP switches used to configure the IRQ
> line on the hardware. If the manual (microcode updates) gives me
> erroneous information, then I put the switches back to their initial
> position (factory microcode). You will disagree and say that, as long as
> it can be updated, and source code exists for it, it is software, not
> hardware.
> 

Let's leave this aside. If it was a picture of something nice instead 
of microcode you would still have legal complications depending on the license.
When you include a work in another you create a derivative work and 
need permission from the copyright holders of both. No one asks you what
the works are (ok, yes, they do, but that's for details).

You can translate that to ethical terms about using the work of others
respecting their conditions if you wish. 

> How about something simple, such as
> 
>         Unselect this option if you do not wish coreboot to update the
>         CPU microcode, or if you experience  issues arising from
>         updating the microcode.
>

Shouldn't we tell something about how to tell an issue arises from 
updating the microcode? I can't. Other than trying to disable it.
 
>         Note that microcode updates are designed to fix issues and bugs
>         in the CPU. Also most operating systems will update the
>         automatically, so you may still end up running with an updated
>         microcode.
>

Good
 
> 	You may, at your option, select to disable microcode updating
>         if you believe it to be in violation with your views on software
>         freedom.
> 
>         If unsure, select y.
> 
> This is accurate to the best of my knowleddge.
> 

I think it misses three facts:

- the issues arising from the microcode updates have been observed
  (are not hypothetical). But this is not giving much information either.

- the license of the microcode patches is not free (how can you believe
it to be in violation of freedom if you're not told this?)

- coreboot does not include all microcode updates ever produced by the
manufacturer (my intention is to be fair if some issue is not due to
something in the microcode patch but to misapplication by coreboot or
lack of fresher updates).

But I don't care. I can accept your text. It's an expert option, shouldn't
need a perfect help.

> IANAL, while a fact, is irrelevant in a help menu. Your profession, or
> mine for that reason, has no relevance in the context of deciding
> whether or not to disallow microcode updates.
>

If one reason is legal complications, and who says it is not a lawyer,
it's relevant. I think the objections where more about : there's no "I"
in a Kconfig file that can be lawyer or not, and uncertainity is to be
avoided because it has an unprofessional look and is perceived as 
complicating usage .

> We want coreboot to be practical. The "maybe" can fill up a text file
> larger than the coreboot source. We don't care. If disabling microcode
> updates works for you, that is sufficient reason to consider this option
>

Certainly. I wasn't pretending to put that text in the help, only explaining
why I couldn't put anything useful.
 
> And yet we still do update the microcode for the majority of users, 

This has ethical consequences but might be made legally simpler by
reading microcode patches from external files.

> and
> we even ship it to you when you download the coreboot source. 

in the source it is more an agregation that a derived work. It's compiling
that makes the derived work. Or maybe I'm confused.

> There is
> practicality arising from thought alone, only giving you the choice to
> exire from the complications the rest of us subject ourselves to, if any.
>

I didn't understand, sorry.
 

> It almost an unwritten law ,not just in coreboot, but in anythat ones
> first patch will not get accepted without at least a revision. It is a

I hope no patch is accepted without a revision, first or
otherwise. This is not exclusive of coreboot, and it is good policy.

> because of points of view differing, or the mud getting too deep. You
> should only quit if you feel you lost interest, or rather, if you stop
> feeling any interest. Whether you are laying down your arms from

Right, I'm not interested in refining this patch further [nor in
power, masculinity, initiation rites, survival by programming firmware
or many other things].
  
It's also nice to quit when you feel you cannot offer anything useful.
We only live so long.