Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
(Thanks for obliging, Henrik. ;-)
On Sun, Sep 8, 2013 at 5:34 PM, Henrik Ahlgren <pablo@seestieto.com> wrote:
> On Sun, Sep 08, 2013 at 08:00:12AM +0900, Joel Rees wrote:
>> (1) This requires enabling two repositories that I have been avoiding
>> enabling, contrib and non-free. That means I have to watch the
>> repository more carefully when using
>>
>> apt-cache search
>>
>> or synaptic to look for new tools, right? Or can we just enable those
>> two repositories long enough to load Henrique's tool and the microcode
>> updates, then disable them again?
>
> Why do you feel that you even need to ask? You are free to handle the
> situation with your machines in any way you wish. Perhaps just
> download and install the .deb packages directly without even using
> apt, or simply ignore the microcode update as shipped by Debian or as
> BIOS upgrades by your computer manufacturer.
I'm thinking like a newbie. (Relative to debian, I am. :-/)
I know there is a tendency to send newbs to Ubuntu. I don't think
that's a good idea any more, for reasons you may not agree with, but I
am sure you are aware of. I am subconsciously thinking about starting
a new re-mix of debian that will focus on people who just want to
replace MSWindows and MacOSX.whatever with something that doesn't try
to own them, but don't have them time/confidence to learn how to do a
manual install of a .deb package.
And as long as Intel is so not-forthcoming, there is no point in doing
so for x86/amd64 CPUs.
>> (2) Are there any CPU manufacturers who are not plagued by this
>> ultimate refusal to let computer owners actually own their computers?
>
> At least Intel openly admits that their modern CPUs have the ability
> to change the microcode by uploading an encrypted binary blob. This
> universal backdoor is publicly documented[1].
You mean, the existence and location are publicly documented, but nothing else.
> Other manufacturers may
> claim otherwise, but what else can we do except trust them? It is a
> very fundamental problem.
And at least the mob admits they want to influence you.
Ken Thompson pointed out the problems inherent in trusting machines as
complex as computers. He also made some mis-targeted assertions about
culpability that are very relevant. He did not provide a solution.
We know the solution, but we don't want to admit that Stallman was
right. We don't think we know where to go from where he takes us.
(Why is decentralization so hard to understand?)
> Also, it is hard to argue that it is useful to have the ability to fix
> bugs in the CPU without replacing the chip.
I think you mean, hard to argue with the usefulness?
But, you see, I'm arguing that complex CPUs are evil. Somewhere in my
arguments is the idea that you could produce a CPU simple enough that
field upgrades would be unnecessary.
> After all, you will face
> the same dilemma of trusting the CPU manufacturer when offered a new
> revision of the physical CPU with bugfixes.
Actually, the dilemma goes back farther than that. How can you trust
the CPU manufacturer when
(1) you can't see the masks and you couldn't read them if you could,
(2) you can't see the manufacturing processes and you wouldn't know
where to look if you could,
(3) no single engineer can understand a modern CPU (and you probably
aren't one of the group that could get close),
(4) etc.
That's more than two lemmas. Darn.
> It simply is not feasible
> for the majority of people to reverse engineer the silicon for any
> evil features like NSA backdoors in any hardware crypto features.
And that's another set of problems.
> Does anyone know if the microcode shipped by Intel is always
> encrypted?
Jack provided a link. (And Henrique brought it into this thread.)
> Their nasty licence prohibits "everse engineering,
> decompilation, or disassembly" of the blob, but even if you ignored
> that,
(See said link, and kudos to someone for going that far down the road.)
> or even if you had the source code (whatever that means in the
> context of microcode, it is not normal X86 code after all), could you
> make any sense of it without having the whole silicon design
> available?
Microcode source code is only a little harder to read than ordinary
machine code. Sometimes it's easier. It's machine code, after all,
even if it isn't the machine code the user usually works with. The
problem is access to the machine that executes the microcode.
Gate arrays and such are not programmed with a machine language, per
se, and are significantly harder to reverse engineer.
But if Intel publicly documented the gate arrays and microcoded
machines used in their CPUs, the updates would not be beyond the reach
of some engineers not employed by Intel. Provision of the gate array
definitions and the microprogramming would add eyeballs to the job of
finding bugs, as well. That leaves the manufacturing processes opaque,
but even those would be more subject to probing if Intel were more
forthcoming.
> [1] http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html
Yep. The say the update method is there, they tell how to call it and
pass in the update, and nothing else. "At least, ... ."
As Henrique points out, even AMD does better than Intel on documenting
this kind of stuff. Not much better, but better.
--
Joel Rees
Reply to: