<div dir="ltr"><div>Hi,</div><div><br></div>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.<div><br></div><div>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. :)</div><div><br></div><div>For some context, see:</div><div><a href="https://lwn.net/Articles/744818/">https://lwn.net/Articles/744818/</a><br></div><div><br></div><div>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)</div><div><br></div><div>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<br><br>Do I expect you could introduce a very subtle security vulnerability with it? Absolutely. The spectre microcode patches effectively do the reverse of that.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>[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.</div><div><br></div><div>Sincerely,</div><div> -Matt</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 24, 2018 at 6:00 AM, <span dir="ltr"><<a href="mailto:coreboot-request@coreboot.org" target="_blank">coreboot-request@coreboot.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Message: 8<br>
Date: Wed, 23 May 2018 22:37:47 +0100<br>
From: Andrew Luke Nesbit <<a href="mailto:ullbeking@andrewnesbit.org">ullbeking@andrewnesbit.org</a>><br>
To: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
Subject: Re: [coreboot] When does AMD release the fam15 spectre<br>
microcode updates?<br>
Message-ID: <<a href="mailto:f840a373-0169-ec59-11f6-4f5d25219784@andrewnesbit.org">f840a373-0169-ec59-11f6-<wbr>4f5d25219784@andrewnesbit.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 23/05/2018 20:55, ron minnich wrote:<br>
> <br>
> <br>
> On Wed, May 23, 2018 at 12:54 PM Rudolf Marek <<a href="mailto:r.marek@assembler.cz">r.marek@assembler.cz</a><br>
> <mailto:<a href="mailto:r.marek@assembler.cz">r.marek@assembler.cz</a>>> wrote:<br>
> <br>
> Hi all,<br>
> <br>
> Dne 22.5.2018 v 07:03 <a href="mailto:Taiidan@gmx.com">Taiidan@gmx.com</a> <mailto:<a href="mailto:Taiidan@gmx.com">Taiidan@gmx.com</a>><br>
> napsal(a):<br>
> <br>
> <br>
> > don't they have those in this update? Would it be possible to<br>
> easily add<br>
> > the support flags without microcode for those who use libreboot?<br>
> <br>
> So libreboot guys don't want any fixes for a CPU?<br>
> <br>
> <br>
> I've been wondering about this. IIRC the original motivation for the<br>
> libreboot fork was microcode.?<br>
> Is microcode still out of bounds for libreboot?<br>
<br>
I don't know if the original motivation still applies. This is an<br>
important discussion to have.<br>
<br>
I've pinged the folks in #libreboot and #vikings on Freenode to alert<br>
them to this discussion. There are probably other relevant channels<br>
I've missed.<br>
<br>
Hopefully somebody with a wider and deeper understanding of the issue<br>
than I have is reading this list. Hopefully they will chime in and<br>
provide a more authoritative answer. If not I will keep pestering them<br>
because I don't want to see this unresolved, but I would like to help<br>
out however I can and learn whatever is needed to make a positive<br>
contribution.<br>
<br>
Andrew<br>
-- <br>
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9<br></blockquote></div></div></div></div>