On 21.03.2018 00:03, Taiidan(a)gmx.com wrote:
On 03/20/2018 06:14 PM, Nico Huber wrote:
patches need to be added stat
You obviously have no idea what you are talking
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
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.
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
Almost every linux distro redistributes them without issue and intel is
suppository a coreboot contributor (to which I have been reminded of
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
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.
- the stakes are too high for this to take months.
You still didn't get what Spectre is about, did you?
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-
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
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