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

[Martin Kepplinger]

Am 21.03.2018 11:13 schrieb Nico Huber:
> On 21.03.2018 00:03, Taiidan at gmx.com wrote:
>> 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?
> 
> You. You seem to rate the convenience to have a binary in the blobs
> repository higher than possible redistribution issues.
> 
> Though, we might have a simple misunderstanding here. I now realized
> that you were trying to cherry-pick that commit into a different re-
> pository. This thread is about a change to the blobs repository which
> is independent of the coreboot source repository and has different
> rules.
> 
> Anyway, I wasn't telling not to fix it, I was just offended by the way
> you want to fix it and your arrogance. You can mitigate Spectre in many
> ways. These microcode updates are just part of one way. And putting
> them into coreboot is just one way to apply them. And having them in
> the blobs repository is just for convenience. Yet, you claimed the lat-
> ter must happen.
> 
>>> 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)
> 
> The files are explicitly distributed by Intel for Linux distributors, 
> we
> are not a Linux distributor. And, FWIW, Intel hasn't ever contributed 
> to
> our blobs repository.
> 
>> 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.
> 
> You are already free to add any microcode update to coreboot you want.
> And we kind of ask people by prompting during coreboot configuration.
> Not every license is an EULA btw.
> 
>> 
>> 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.
> 
> Yep, but they were submitted a long time ago. And that stopped at some
> point. I don't know yet if due to licensing issues or just because it's
> more convenient for Google to maintain their own, hidden blobs repo.

FWIW, my understanding is that Intel *calls* this microcode release 
"Linux".
Nothing in the license text refers to Linux or Linux distributors. In 
principal
it is distributable. The relevant OEM part of the license basically says

* only use with Intel CPUs, only under this license
* don't reverse engineer
* only distribute in conjunction with a "written license aggreement" 
like a
"break-the-seal license" to "safeguard Intel's ownership rights".

That last part may indeed be tricky. Other than that, it may be good to
include the license text in the blobs repo directly.

IANAL, but coreboot might not be compliant indeed now. I can imagine
*some* way of achieving compliance like a prominent statement with
"press any key" during the build process though.

Coreboot should (only) care about *it's* users and pass on this license 
to them
(distributors or whoever, who then can deal with it too).

In short: We can greatly improve the situation quite easily, and 
probably
should do so. Thanks for bringing this up.

> 
>>>> - 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.
> 
> So does Rowhammer, any caching related side-channel attacks, hyper-
> threading related side-channel attacks, I don't know maybe more. These
> attacks exist and are possible, some may be more complicated than
> Spectre but most of all: They are not as popular as Spectre.
> 
>> What other exploits exist which can easily read data from a VM's host?
> 
> Sorry, easily? Even a Spectre attack isn't that easy. It depends a lot
> on the code around your VM (no matter the microcode updates in ques-
> tion). You can make it secure against Spectre even without these micro-
> code updates.
> 
>> 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.
> 
> Good analogy, you are right. No matter how careful you are, you may get
> powned at some point. But what you suggest doesn't seem much better,
> trigger all mines you can spot all day with a gas mask on that only
> protects you against one kind of mines that hasn't been spotted yet in
> the wild.
> 
> Nico