[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)



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.

> (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]. Other manufacturers may
claim otherwise, but what else can we do except trust them? It is a
very fundamental problem.

Also, it is hard to argue that it is useful to have the ability to fix
bugs in the CPU without replacing the chip. After all, you will face
the same dilemma of trusting the CPU manufacturer when offered a new
revision of the physical CPU with bugfixes. 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.

Does anyone know if the microcode shipped by Intel is always
encrypted? Their nasty licence prohibits "everse engineering,
decompilation, or disassembly" of the blob, but even if you ignored
that, 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?

[1] http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html


Reply to: