[coreboot] [PATCH] disabling microcode update

[Alex G.]

On 02/26/2011 10:19 PM, xdrudis wrote:
> On Sat, Feb 26, 2011 at 04:01:56AM +0200, Alex G. wrote:
>> On 02/26/2011 03:38 AM, xdrudis wrote:
>>> This is the patch for option B. 
>>>
>>> You may not be able to test it without my next patch. At least for me 
>>> selectiong EXPERT in make menuconfig breaks the build. Next patch fixes it.
>>>
>>>
> 
>> I don't like the wording for the help option. 
> 
> Stefan Reinauer didn't like it either and I'm not sure he does now.  I
> got no suggestions (alternative wordings) so I changed only the
> particulars he pointed to.  Feel free to improve it.
> 
> [note: this pretty much summarised the other 120 lines, in case
> you don't read it all]
> 
>> It creates the impression
>> that the entire reason for this option is purely philosophical.
> 
> Not having the source, documentation and specific expertise 
> is a philosophical problem but not only 
> a philosophical problem. One of the consequences is that I can
> not give any satisfactory practical reasons for updating or not
> updating microcode.
>
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.

> All I could write would be 
> 
>           Select this to apply non-free patches to the cpu
>           microcode provided by AMD to correct issues in the CPU after
>           production, and distributed with coreboot (not necessarily
>           the latest microcode version produced by AMD, but only
>           applied if newer than the version in your CPU). 
> 
>           The microcode patches are selected from mainboard Kconfig
>           AMD_UCODE_PATCH_FILE among the
>           src/cpu/amd/model_10xxx/mc_*.h files provided by AMD. We
>           don't know the issues solved by each microcode patch file,
>           the issues created by each file (possibly solved in other
>           patches present in or absent from coreboot) or the
>           preconditions to apply them to your particular CPU or to the
>           set of CPUs the image you're configuring may run on.  We
>           know the intent of the patches is to solve issues and that
>           we've had systems running well with the patches and issues
>           also solved by not applying them.
>           
>           Unselect to let FAM10 CPUs run with the unpatched microcode
>           as shipped from factory.  If you unselect this, no binary
>           microcode patches will be included in the image, so it will
>           help you get an image which you have the entire source code
>           for and may simplify license compliance.
>           
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.

        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.

	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.

> But since Stefan didn't like "IANAL", I bet he won't like this either.

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.

> And maybe others here know more than what I just wrote, or it's
> published somewhere, it's just that for philosophical reasons, and the
> practical reason that it seems to work without updating microcode for
> me, I'm not interested in investigating the microcode details, and I
> suspect as much of Ivaylo.  Maybe Ivaylo and I picked the wrong mc*.h
> file, maybe the right one isn't there, maybe the checks before the
> microcode update are somehow wrong, maybe our CPU is newer than the
> mc*.h files and it somehow fools the checks, maybe it's just wrong to
> have AMD_UCODE_PATCH_FILE as a mainboard option, and a rutime check
> should select, for each processor, beetwen all microcode patches
> available, so that a coreboot image could run on any CPU revision you
> can put on that board and socket. But I can't get past "maybe".
> 
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

>> That is not to say
>> to avoid the philosophical issue altogether, but not invoke it as the
>> main reason.
>>
> 
> I think you overestimate the philosophical nature of practical reasons 
> such as a simpler license compliance or working with a source backed code
> base. Of course they carry philosophical questions of no small importance
> and even epistemological questions here noted, but less legal trouble
> and less unknowns are practical reasons as well. 
> 
And yet we still do update the microcode for the majority of users, and
we even ship it to you when you download the coreboot source. 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.

>> Other than that, pretty good job :)
>>
> 
> Thank you.
> 
> I hope Stefan and Peter agree with you, because I don't. For me it looks
> uglier each time. 
> 
> In fact this is starting to feel like design by committee. I think I'm
> doing something without further researching some parts because I'm not
> interested, and, although I wouldn't have bothered the list without
> practical reasons, I'm more motivated for legal peace of mind and
> software freedom than for the practical reasons, so I'm relunctant to
> hide it or to attribute it to practical reasons. And you (and possibly
> others) are trying to accept a new option because you want to be nice,
> sympathise with some general philosophy, and are concerned with
> accomodating all use cases but you think it will hardly ever work so
> you want it hidden, explained and with warnings. 
> 
> In a way we both stand in a quasi contradictory position each and are
> trying to reconcile these different positions. If I liked this sort of
> bargaining I'd send a resumé to the European Council. I'm all for peer
> review (no offense intended calling you my peers) and throwing more
> eyeballs at things, and discussing stuff until we're all convinced, but
> I've run out of time and motivation, and i don't really find I have
> much more to offer.
> 
> If anyone wants to take it from here you can refine and commit one
> of these patches (option A or B), or come up with something new, 
> but it will take someone more aligned with the general sentiment
> than myself, to really code something that makes sense to herself and
> later can be made acceptable to all. So I'll leave it here.
> 
> Thanks to all for your attention and sorry for not being able of more. 
>  
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
thoughtless initiation rite, an unconscious demonstration of power and
masculinity from those veteran enough to afford it. It is also a way to
ensure succession over generations: to get you thinking more deeply
about the code you modified, to understand it better, to inescapably see
it in your dreams, so that when you wake up, you will improve it more,
all in an attempt to get YOU to continue contributing. It is an instinct
of survival.

I'm not one of the core developers. I'm just a vigilante patching a
broken society. I'm actually incredibly virgin to the project, only
having joined last month. I get put through the same treatment, and I do
not find offense in it. I am not told that my work is broken, but _why_.
This _why_ is the only way to advance the ranks to the point of ensuring
heredity to the project. Whether I will continue to chase lawless
criminals, invest countless sleepless hours, and abstain from basic
nutrition in the desire to aquire the hardware necessary to do so, is
unbeknownst to me. And I do not care. I make the best of the time I
spend _now_ .

Shortening the server-kneeling spree of characters, you should not quit
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
exhaustion or your country has more appealing issues at hand, only you
can decide.

Alex