[coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[Taiidan at gmx.com]

On 03/20/2018 06:14 PM, Nico Huber wrote:

>> These patches need to be added stat
> You obviously have no idea what you are talking about.
What makes you say that?
> AFAIK, nobody who has the right to submit to the blobs repository has commented yet on
> newer microcode updates or was asked personally if this is acceptable.
> You might have noticed that microcode updates are not public domain but
> licensed.
Almost every linux distro redistributes them without issue and intel is
suppository a coreboot contributor (to which I have been reminded of
multiple times)

I don't see as to how that is something that can't be worked around by
asking people to download it themselves from a browser or making a shell
script that imports intel's EULA and asks the user to agree to it before
downloading it when they compile coreboot.

Other microcode updates are included coreboot so are a variety of ME
images and other binary blobs from intel so I fail to see the
distinction here.
>> - the stakes are too high for this to take months.
> You still didn't get what Spectre is about, did you? 
I do.
> It's just one of many side-channel attacks that are possible when you run untrusted code on your machine.
The whole point of a VM is that you are able to run untrusted code with
some decent level of isolation and spectre ruins this.
What other exploits exist which can easily read data from a VM's host?
If there is a fixable problem why not fix it?

The idea that the only way to go about things is to trust all the code
that runs on your computer is backwards and unrealistic as even if you
only ran foss programs on a modern linux you still have millions of
lines of un-audited code loaded with exploits.
> These updates just help with one instance of a much bigger problem and won't magically make your computer (and the software you run) secure.
Yes obviously but this is saying that because you can't be fully secure
you shouldn't bother with anything at all.
> Have a look at [1] or uMatrix. These are much better mitigations, IMHO.
> But if you are really security concerned you already know that anyway.
That wasn't the question and I don't appreciate replies like this.
Should firmware programmers be the only ones using coreboot? I have
patched my kernel and various other programs before but I have no reason
to use git and I couldn't figure this out myself.

If you were a sysadmin for a large company would you tell them to not
bother applying the spectre mitigations? should their users use umatrix
instead and that anyone who accidentally enables a site with encryption
key/password stealing malicious javascript gets fired? Enabling
javascript on a per site basis is like playing minesweeper - eventually
you will step on a mine no matter how careful you are.

I have to use javascript for many websites I need which is why I have a
browser in a VM just for them but I don't want them to be able to be
able to read host memory or the memory of other VM's.