[coreboot] When does AMD release the fam15 spectre microcode updates?

[Matt B]

Hi,

My deepest apologies if this doesn't show up in the right spot, despite
editing the subject. I'm a dummy and I'm switching off digest mode right
now.

I'm no expert on microcode but I'll share my personal stance which I think
is pretty reasonable and practical. As the saying goes, the best way to ask
a question on the Internet is to give the wrong answer. :)

For some context, see:
https://lwn.net/Articles/744818/

My understanding of microcode, both from what I've read and what I've
studied is that it is or is more analogous to the contents of one or more
state tables, for state machinery in the CPU, and most useful for handling
complicated functionality (like a multi-word copy). (the actual details are
probably a hugely proprietary secret)

I seems to me that most people hear the 'code' part of 'microcode' and
assume it's a huge compiled binary blob running on a general-purpose
processor, and can do just about anything and attacker could possibly want.
I wrote this sentence, then then realized that everyone knows that's what
the IME is for. ;D

Do I expect you could introduce a very subtle security vulnerability with
it? Absolutely. The spectre microcode patches effectively do the reverse of
that.

Do I worry about that too much? Not really. My reasoning is that it would
be equivalent to introducing it in the in-silicon architecture of the CPU,
and that's already something we *assume* Intel/AMD/ect don't (or shouldn't,
for practical/legal/moral reasons) do. We can talk about silicon poisoning
later over (preferably alcoholic) beverages.

Do I think that this has any bearing on whether you should install
microcode patches? Not really, no. Microcode patches are (typically)
created to fix some specific errata. You could make some argument that they
also provide the opportunity introduce/remove some vulnerability, since
they can't really be inspected that well (or at all), but I refer you to #2.

Since they typically exist to fix some (sometimes serious) errata I install
them as a matter of "best security practice" like I do for innumerable
software updates.

Note that all of the above is purely from a practical stability/security
perspective. Proprietary IP (code and otherwise) permeating everything we
use at a deep level is also a huge moral issue (or so I am repeatedly told
:D), it's just that I tend to focus on the practical aspects/implications.

That said, even if you have stronger free-software moral fortitude than me
[1], I can't fathom why you wouldn't install a microcode patch. You're free
to abstain, but I would *mostly* equate running a CPU with unpatched
microcode with running one that's patched. I say mostly, because I consider
the patching to be small potatoes, especially compared with, say, not
infecting your friends with a virus that exploits a significant errata. (I
won't say more on this though, since I've probably already just ensured a
"lively" ethics debate. I just want the option to load the damn things.)

Don't get me wrong, for both moral and practical reasons I would love more
than anything to be using a 100% open computer. But I would have to not
ignore hardware in that, especially if we count microcode. I don't think we
can expect Intel/AMD/ect to release the complete design of *any* CPU since
at least the Z80, and that still may not do anyone any good if they're the
only ones making them. I think the best we can look forward to on that
front right now right now is RISC-V hitting silicon from a variety of
manufacturers. I recently saw their dev board running youtube videos, so
that looks promising.

[1] I will, on occasion, use N-F software *Gasp!* that's convenient *Gasp!*
and from sources I sufficiently trust in contexts where that trust is
sufficient.

Sincerely,
    -Matt

On Thu, May 24, 2018 at 6:00 AM, <coreboot-request at coreboot.org> wrote:

> Message: 8
> Date: Wed, 23 May 2018 22:37:47 +0100
> From: Andrew Luke Nesbit <ullbeking at andrewnesbit.org>
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] When does AMD release the fam15 spectre
>         microcode updates?
> Message-ID: <f840a373-0169-ec59-11f6-4f5d25219784 at andrewnesbit.org>
> Content-Type: text/plain; charset=utf-8
>
> On 23/05/2018 20:55, ron minnich wrote:
> >
> >
> > On Wed, May 23, 2018 at 12:54 PM Rudolf Marek <r.marek at assembler.cz
> > <mailto:r.marek at assembler.cz>> wrote:
> >
> >     Hi all,
> >
> >     Dne 22.5.2018 v 07:03 Taiidan at gmx.com <mailto:Taiidan at gmx.com>
> >     napsal(a):
> >
> >
> >     > don't they have those in this update? Would it be possible to
> >     easily add
> >     > the support flags without microcode for those who use libreboot?
> >
> >     So libreboot guys don't want any fixes for a CPU?
> >
> >
> > I've been wondering about this. IIRC the original motivation for the
> > libreboot fork was microcode.?
> > Is microcode still out of bounds for libreboot?
>
> I don't know if the original motivation still applies.  This is an
> important discussion to have.
>
> I've pinged the folks in #libreboot and #vikings on Freenode to alert
> them to this discussion.  There are probably other relevant channels
> I've missed.
>
> Hopefully somebody with a wider and deeper understanding of the issue
> than I have is reading this list.  Hopefully they will chime in and
> provide a more authoritative answer.  If not I will keep pestering them
> because I don't want to see this unresolved, but I would like to help
> out however I can and learn whatever is needed to make a positive
> contribution.
>
> Andrew
> --
> OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180609/5123def3/attachment.html>