Re: [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,  wrote:

> Message: 8
> Date: Wed, 23 May 2018 22:37:47 +0100
> From: Andrew Luke Nesbit 
> To: coreboot@coreboot.org
> Subject: Re: [coreboot] When does AMD release the fam15 spectre
> microcode updates?
> Message-ID: 
> 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  > > wrote:
> >
> > Hi all,
> >
> > Dne 22.5.2018 v 07:03 taii...@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 

Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)

[Jose Trujillo via coreboot]

Dear Rudolf/All,

Today I tried several things to try to make COM1 to work unsuccessfully.

In my last test today I crossed the COM configuration from:

COM1 (not working)COM2 (OK)
0x3f8, IRQ4  0x2f8, IRQ3

to:

0x3f8, IRQ3 0x2f8, IRQ4  (Both not working)

My conclusion (I coudl be wrong) on this is that both resources 0x3f8, IRQ4 
(COM1) are being used by coreboot or FSP.

Anyone could give me a hint how to release those resources to be used by my LPC 
SIO chip. 

Thank you.
J. Trujillo

‐‐‐ Original Message ‐‐‐

On June 6, 2018 11:46 PM, Rudolf Marek  wrote:

> Hi,
> 
> In general I would check ELCR (I/O port register 0x4d0) to check if it is 
> correctly programmed to EDGE/LEVEL (it should be edge)
> 
> Also, how the Linux is supposed to detect the I/O port irq? I think you need 
> some PNP device in ACPI to let linux infer the IRQ.
> 
> I would also try to disable the IRQ from SoC, you just need to check how they 
> are enabled (sorry not an expert here)
> 
> and also I would use the legacy 0x3f8 instead.
> 
> Thanks
> 
> Rudolf



-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Intel ME Security keys Genealogy, Obfuscation and other Magic

[Shawn]

https://github.com/ptresearch/IntelME-Crypto/blob/master/Intel%20ME%20Security%20keys%20Genealogy%2C%20Obfuscation%20and%20other%20Magic.pdf

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot