Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
On Mon, Sep 9, 2013 at 12:55 AM, Henrique de Moraes Holschuh
<hmh@debian.org> wrote:
> On Sun, 08 Sep 2013, Joel Rees wrote:
>> I was hoping that AMD was not going to have the license and
>> non-visibility issue that plagues the Intel processor microcode
>> updates. But I find this original announcement from when Henrique made
>> the updater tool available:
>>
>> http://lists.debian.org/debian-devel/2012/11/msg00109.html
>
> AMD is better than Intel at telling the general public what a microcode
> update fixes. AMD does publish to the general public the errata each
> microcode update fixes. What each erratum means is also published in the
> AMD processor "Revision Guides", which are also public.
>
> Not that it will help you much. Really. Most of the errata worth fixing
> through a microcode update causes either unpredictable system behaviour,
> data corruption, or system hangs/reboots. Only a few fixes are for "minor"
> issues such as power management, performance, or optional features. And
> most of the time, it is very very difficult to access how difficult it is to
> hit a given erratum. So it is a "update or else" deal, because it always
> fixes something horrible (even when the chances of you hitting the issue are
> very remote -- but you won't be able to know that, you'll have to update
> just in case anyway)
"<X/> or else ...", when there are secrets being kept always bugs me.
> AFAIK, Intel does publish the same kind of information but it is not
> available to the general public.
I don't really call that publishing. "Publishing privately" is one of
the conceits introduced at Berne that undermine the principle of
copyrights in free countries.
> Intel does publish to the general public
> the list of errata in their processor "specification updates" documentation,
> it just almost never writes down in public documentation what errata a
> microcode update fixes.
>
> And you could also have internal/non-public errata and fixes, nothing forces
> Intel, AMD, or any other vendor to disclose (even to their hardware
> partners) the full list of errata and behaviour changes (fixes, etc).
>
> Note that even the internal errata/fix information is bound to be really
> uninteresting anyway. Backdoors would not be documented anywhere, heck, it
> is very likely that only the one or two engineers that had to implement them
> even know about it.
Still, secrecy about the microcode and about the updating machinery
makes it that much harder to probe for back doors.
Ken Thompson didn't mention it in his essay, but it is possible to
probe library code for stuff that isn't in the source code. And it is
possible to probe a CPU for backdoors, if you have enough
documentation about their correct behavior.
"Modern" CPUs (particularly x86 and AMD64) are like MSWindows -- too
complex, not accessible to review, no guard rails.
> --
> "One disk to rule them all, One disk to find them. One disk to bring
> them all and in the darkness grind them. In the Land of Redmond
> where the shadows lie." -- The Silicon Valley Tarot
> Henrique Holschuh
--
Joel Rees
Reply to: