On 21.03.2018 00:03, Taiidan@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.
- 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