On 1/15/2018 11:54 AM, Andy Burns wrote:
mike wrote:

Exactly what is microcode in this context?

Recent intel processors don't natively execute x86 or x86_64
instructions that compilers or humans produce, they use a lower level
internal microcoded instruction set. So to a limited degree they can
issue new microcode (which the CPU will only accept if it recognises a
signature on it) that alters how the processor actually runs.

It appears that there's a new class of microcode that can directly
change persistent code within the microprocessor itself???

No intel CPU microcode needs to be loaded into the CPU at every reboot
(by the BIOS, or by the O/S)

Perhaps that's the confusion. Loaded at boot is volatile.
The word "update" implies, to me, a non-volatile fix/patch that needs
to be done once. So, we're overlaying the the microcode
that the BIOS loaded
at power up with microcode that the OS provides??
That gives me more confidence that the "update" won't bork my BIOS.
It shouldn't have to do anything with the BIOS.

all this really any big deal? If it ain't broke...

You don't regard meltdown and/or spectre as evidence of breakage?

I'd use the word, "unfortunate". The black hats found a way to do bad
stuff to a design that's been working ok for decades.

I had an old car that ran fine for decades. It was decreed that
you could no longer get leaded gasoline. It seems that the lead served
some needed function. Later, I had a car that didn't like gas with
alcohol in it. Both still got me from point a to point b.
Is the vendor of the old car responsible for legislated changes in
gasoline composition?

Intel is not the villain here...the black hats are.
It's unfortunate, but bitching about Intel won't do any good.
S#|T happens. You make the best of what you've got and move
forward.

Given the mind-boggling complexity of computer hardware and software,
I'm amazed that it works at all.