[coreboot] [PATCH] disabling microcode update

[Alex G.]

On 02/27/2011 12:46 AM, xdrudis wrote:
> 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).
> 
No, I'm not leaving it aside. The microcode you wish to disable (and
IIRC you, Peter, Stepan, and I agree to providing this choice via an
elegant Kconfig option) was provided by AMD, and they have given us
permission to use it in our code, with our license. In fact, they
provided the (coreboot) patches themselves. The developers provided
permission for the microcode to be used with coreboot, by committing it.

> You can translate that to ethical terms about using the work of others
> respecting their conditions if you wish. 
>
And I just detailed how this applies here.

>> 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.
>  
We should, but at the moment, we don't have enough information. It's a
try before you buy issue.

>>         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.
> 
I would argue that "if you experience  issues arising from updating the
microcode" implies someone has already hit this, but alright, let's
change it to:


        Unselect this option if you do not wish coreboot to update the
        CPU microcode. Some persons have experienced problems with
        updating the microcode that were solved when the update was
        disabled. If you believe you may be experiencing an issue
        related to updating the microcode, unselect this option. There
        is currently little information available on the effects of
        this.

> - 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?)
> 
Third paragraph leaves you, the user, to decide this. We are not the
FSF, we cannot decide for others.

> - 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).
> 
Are you expecting  coreboot to include them all?
> But I don't care. I can accept your text. It's an expert option, shouldn't
> need a perfect help.
Of course you're not. It's an expert option. If you tackle with this
menu, you already know it tries to include the latest microcode
available, not all of them, right?

>> 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 .
> 
And that is exactly what I meant.

>> 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.
>  
The text was the only objection I had, and I hoped we were working to
improve it

>> 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.
> 
Agreed entirely, but as you claim to be lazy and only do it for Fam10
CPUs, so de we, and do not write the infrastructure code to support this.

>> 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.
>
As trunk stands at the moment of this writing, coreboot cannot be
compiled without the microcode, and thus you may very well argue it is a
derived work. Your patch tries to change that, and we agree it is the
better direction.

>> 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.
>  
I meant that I, as a user who compiles with the microcode, expose myself
to the legal issues of including bytecode in a GPL work. You can choose
not to do so by disabling the microcode update.

>> 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.
> 
It is a fact of life, not a policy. We do not artificially, or at least
consciously try to make things hard for newcomers.

>> 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].
>   
I respect your choice.

> It's also nice to quit when you feel you cannot offer anything useful.
> We only live so long.

You have already given us something of extreme value: the impulse to
start considering this issue, the chance to discuss this. You have given
us an idea, which is worth more than a thousand patches. Ideas can exist
without patches, but not the other way around.

I wish you good luck in whatever you may choose to do next, and I want
you to know that we will still be here (hopefully with an open mind)
should you ever need our help. :)

All the best,
Alex