I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre.
I believe this is a relevant coreboot topic considering how many coreboot boards have these and older CPU's....without a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and theoretically owner controllable (as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
Hello,
Off-topic: Top-posted as Protonmail Android App is still unable to correctly use inline answers without correct quote layout/line breaks. Bug has been reported months ago :-/
Taiidan wrote:
"(...) CPU's....without a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (...)"
Currently I am using two laptops for my work setup: A 12.5" Lenovo X230 and a 15.x" Lenovo W540 both machines are running with Qubes OS 4rc3 and 16GB RAM. The W540 is a Dual-Boot system with Win10, the x230 is running Coreboot.
Honestly I am shocked and angry if there will be no Intel Updates for the X230 and W540. On the other hand, if I am running Qubes and Coreboot, wouldn't this reduce the risk of Meltdown/Spectre attacks as Coreboot will protect me against remote attacks (stripped down AMT/Intel ME) and Qubes might reduce the attack surface as I am using several VMs and DVMs for browsing?
If I compare the Lenovo X230 to Lenovo G505s this looks like a step back: the G505s is targeted at another audience that Lenovo ThinkPad Users. It looks to me like an entry level desktop, which is also very bulky (without the additional performance of a W540).
CPU comparison X230 CPU vs G505s http://www.cpu-world.com/Compare/725/AMD_A6-Series_for_Notebooks_A6-5350M_vs...
Also the G505s has less cores/no HT
Frustration. Can't "we" build one or maybe two crowd founded secure Laptops (12", 15.x") with reasonable specs, good keyboard, hardware kill switches, internal wan (kill-switchable)? I can't think that choice is limited in 2018 to only 1 (in words "one") laptop modell, which is no nearly 5 years old (08/2013).
Brave new world.
[799]
Gesendet von ProtonMail mobile
-------- Original-Nachricht -------- An 11. Jan. 2018, 03:55, Taiidan@gmx.com schrieb:
I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre.
I believe this is a relevant coreboot topic considering how many coreboot boards have these and older CPU's....without a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and theoretically owner controllable (as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
On Wed, 10 Jan 2018 21:55:18 -0500 "Taiidan@gmx.com" Taiidan@gmx.com wrote:
I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre.
Not an Intel insider, but here is a list from Lenovo listing affected products and when microcode updates will be available addressing Spectre v2:
https://support.lenovo.com/de/en/solutions/len-18282
X230 is scheduled for 2/2/2018.
I don't know about the X200, but I doubt there will be further microcede updates :/ But actually I don't know.
For meltdown, running the latest kernel should be sufficient I guess, since it has the KPTI patches.
I believe this is a relevant coreboot topic considering how many coreboot boards have these and older CPU's....without a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and theoretically owner controllable (as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Hi Taiidan,
On 11.01.2018 03:55, Taiidan@gmx.com wrote:
I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre.
I believe this is a relevant coreboot topic considering how many coreboot boards have these and older CPU's....without a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and theoretically owner controllable
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop.
(as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
It depends on the software you run. Please read more about Meltdown and Spectre. When you understood it, you can still start to worry.
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
Yes? and that can be accomplished without microcode updates, AFAIK.
Nico
On Thu, January 11, 2018 10:05 am, Nico Huber wrote:
On 11.01.2018 03:55, Taiidan@gmx.com wrote:
only one coreboot compatible laptop with open source hardware initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and theoretically owner controllable
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop.
In its defense, it's one of the few usable laptops that don't have ME or PSP. I did a full Debian kernel build inside a Xen HVM on it the other day in 2.5 hours. I'm sure there's faster but for day to day use it's plenty good for me, even though I do need to tolerate a handful of blobs.
On 01/11/2018 05:05 AM, Nico Huber wrote:
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop.
I forgot to include my usual suffix mentioning that blobs are required for video (and power management)
I believe it is still much better than the C2D laptops in terms of security despite the video blob as it has an IOMMU [1] and no ME/PSP. [1] with the high end quad core CPU option
(as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
It depends on the software you run. Please read more about Meltdown and Spectre. When you understood it, you can still start to worry.
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
Yes? and that can be accomplished without microcode updates, AFAIK.
I was and still am under the impression that fixing both issue classes requires microcode updates, can you link to a better explanation?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
What I'm more concerned about right now is something I'd term "security apathy". We just learned 99% of the world's computers are insecure in one way or another; security is now something that (to most people) apparently cannot be purchased. In such an environment, the cheapest system per unit performance always wins, even if it happens to contain rampant abuses of privacy / backdoors.
Probably a discussion best had over coffee, since it's largely unfixable, but suffice it to say we're already starting to see this even in our original customer base.
On 01/11/2018 04:22 PM, Taiidan@gmx.com wrote:
On 01/11/2018 05:05 AM, Nico Huber wrote:
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop.
I forgot to include my usual suffix mentioning that blobs are required for video (and power management)
I believe it is still much better than the C2D laptops in terms of security despite the video blob as it has an IOMMU [1] and no ME/PSP. [1] with the high end quad core CPU option
(as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
It depends on the software you run. Please read more about Meltdown and Spectre. When you understood it, you can still start to worry.
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
Yes? and that can be accomplished without microcode updates, AFAIK.
I was and still am under the impression that fixing both issue classes requires microcode updates, can you link to a better explanation?
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
This assumes security was a concern in the first place, which is not what I see where I live/work.
On 01/11/2018 11:27 PM, Timothy Pearson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
What I'm more concerned about right now is something I'd term "security apathy". We just learned 99% of the world's computers are insecure in one way or another; security is now something that (to most people) apparently cannot be purchased. In such an environment, the cheapest system per unit performance always wins, even if it happens to contain rampant abuses of privacy / backdoors.
Probably a discussion best had over coffee, since it's largely unfixable, but suffice it to say we're already starting to see this even in our original customer base.
On 01/11/2018 04:22 PM, Taiidan@gmx.com wrote:
On 01/11/2018 05:05 AM, Nico Huber wrote:
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop.
I forgot to include my usual suffix mentioning that blobs are required for video (and power management)
I believe it is still much better than the C2D laptops in terms of security despite the video blob as it has an IOMMU [1] and no ME/PSP. [1] with the high end quad core CPU option
(as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
It depends on the software you run. Please read more about Meltdown and Spectre. When you understood it, you can still start to worry.
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
Yes? and that can be accomplished without microcode updates, AFAIK.
I was and still am under the impression that fixing both issue classes requires microcode updates, can you link to a better explanation?
Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJaV+TkAAoJEK+E3vEXDOFbghEH/ivQ84bm11KHSDs8+EIWSP1J XeQvhxHlsz5ZNYA16a7QU+dWhn8vOo6es3yBmTgOPsVzu1PUgXwgX1QnfUyAzrml 59d7TZE7p8MtgCAmsUruNgVdPgXEPK/Qh/6uUarVh8U7bRpaOEVcc2thJZCRDLQw U4m8+Z5RudnDz9ZiPVfMKhpqSVJ+FTBzr3uCp+Mqr9CFIV3GxbwWCkoEPbo1hNrq O+ZfCk24GseFfI8fjfpP523nARd8bX0WEUodRaw/l58+vspjGo3DyvjrWpcdJRHg X+dg0I9CKVPt7doFh4NscPmNAhia9R8JfeTj3qCoMiFAvSHcBgb7p8Q8xitIkw0= =gkEr -----END PGP SIGNATURE-----
On Thu, 11 Jan 2018 17:22:48 -0500 "Taiidan@gmx.com" Taiidan@gmx.com wrote:
On 01/11/2018 05:05 AM, Nico Huber wrote:
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop.
I forgot to include my usual suffix mentioning that blobs are required for video (and power management)
I believe it is still much better than the C2D laptops in terms of security despite the video blob as it has an IOMMU [1] and no ME/PSP. [1] with the high end quad core CPU option
(as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
It depends on the software you run. Please read more about Meltdown and Spectre. When you understood it, you can still start to worry.
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
Yes? and that can be accomplished without microcode updates, AFAIK.
I was and still am under the impression that fixing both issue classes requires microcode updates, can you link to a better explanation?
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysi...
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Hi Nico,
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your requirements it's not usable as a laptop
I've had a small discussion with bridgman from AMD (at Phoronix forums) and he told me that VBIOS needed by G505S - aka "gfx init for AMD" - - is "effectively open source" - a byte code which is possible to parse with [AtomDis] open source interpreter
Only problem is that the last update of AtomDis was at 2011 - so, while it should be able to parse 100% of G505S integrated / discrete GPUs AtomBIOSes (because these GPUs were developed before 2011 if I am correct) maybe AtomDis couldn't parse everything for the modern AMD GPUs
Me:
" @bridgman why you don't just open source the complete source code of VBIOS, to let the open source community improve it and fix some bugs? With the help of flashrom open source project, anyone is able to reflash their VBIOS through In-System-Programming. We just don't have the original source code of VBIOS, and the creation of open source VBIOS from scratch is like reinventing the wheel - a huge wheel, which is way too much for unpaid work
Just share the complete source code of VBIOS and let the open source community fix the bugs for you for free! A win-win solution. Why not do it? For the bystanders like me, it gives an impression that either 1) VBIOS source code is a horrible quality, too ashamed to release it to public 2) VBIOS contains some hidden backdoors, hence the need for secrecy 3) AMD is not that friendly to open source community, if instead of sharing what you already got, you want the people to start reinventing the wheel and waste countless of unpaid work hours on it "
brigman:
" It is effectively open source. The data tables are all documented in atombios.h. They are just data structures. The command table parameters are all documented in atombios.h (also just data structures). The command tables are all written in byte code to begin with. The source to the interpreter is open source so you can dump command tables and see exactly what they are doing. You can even write your own command tables in byte code or edit exiting ones if you wanted to. Those are the only things the driver uses from the vbios. The whole point of the data and command tables is to encapsulate board specific configuration details on the actual board itself so that the driver doesn't need explicit knowledge about every board configuration out there.
To summarize:
1. We use an interpreter in VBIOS in order to (a) fit a lot of functionality into a small ROM, (b) give us a degree of CPU independence. My understanding is that this is pretty common practice; either way it's not likely to change unless OEMs buying AMD chips are willing to spend more $$ on the ROM for our hardware than for competitors hardware AND we are willing to go back to having different BIOS code for each of the different CPUs our chips are used with.
2. As agd5f said, the VBIOS source code is bytecode similar to what you get out of the disassembler, although the disassembler output is formatted more neatly. It's not like there is a single master copy of VBIOS source written in C that could be "opened once" - every HW vendor tweaks their BIOS images before production and AFAIK those changes are not ours to publish.
Relatively more of the changes are in data tables than in command tables but both get changed and so we need to use both in the driver if we want driver functionality to correctly match the HW config. There are literally thousands of different HW subsystems, each with their own VBIOS image and hence each with their own slightly different source code... and the associated HW differences DO generally need to be considered when the driver runs.
3. A couple of people have started projects to replace VBIOS with a fully open solution, but my impression is that they all run into the same issues:
- initial implementation is straightforward but ongoing maintenance is a big and boring effort nobody wants to own - you lose CPU independence unless you are willing to maintain AND TEST a lot more different VBIOS builds - without an interpreter the resulting implementation won't fit in the on-card ROM unless you cut back functionality
We make enough information for an open source BIOS replacement available as part of the open source driver effort (data table & command table headers, bytecode interpreter, open source drivers using the tables) although I don't think we support VBIOS re-flashing in general. It is easy to get the same result by over-riding tables in the driver code, however, and I believe there is an existing quirk mechanism.
4. Over time I think you will see a trend away from using AtomBIOS calls simply because ROM size limits the amount of complexity that can be supported in ROM-resident tables while HW complexity is continuing to grow as quickly as ever.
My understanding is that DAL/DC makes somewhat less use of AtomBIOS calls but it also replaces a relatively painless sharing model (drivers for all OSes/platforms make the same AtomBIOS calls for the fiddly HW-specific bits) with a much-harder-to-sell sharing model (drivers for all OSes/platforms share native driver code for the fiddly HW-specific bits).
I understand that this seems unnecessary (and maybe even counter-productive) if you believe that modesetting is trivial, but I don't know how to reconcile your views on modesetting with the views of developers working on the code at different vendors. Once we figure out how to close that gap the rest of the discussion should become easier. "
Best regards, Mike Banon
On Thu, Jan 11, 2018 at 1:05 PM, Nico Huber nico.h@gmx.de wrote:
Hi Taiidan,
On 11.01.2018 03:55, Taiidan@gmx.com wrote:
I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre.
I believe this is a relevant coreboot topic considering how many coreboot boards have these and older CPU's....without a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and theoretically owner controllable
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop.
(as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
It depends on the software you run. Please read more about Meltdown and Spectre. When you understood it, you can still start to worry.
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
Yes? and that can be accomplished without microcode updates, AFAIK.
Nico
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
On 01/11/2018 03:55 AM, Taiidan@gmx.com wrote:
I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre.
Looks like they're available now. Has anyone tested them yet?
https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Da...
Am 14.03.2018 22:46 schrieb David Hobach:
On 01/11/2018 03:55 AM, Taiidan@gmx.com wrote:
I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre.
Looks like they're available now. Has anyone tested them yet?
https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Da...
I have. I have the relevant patchset up for review: https://review.coreboot.org/#/c/blobs/+/23315/ and currently always apply it on top of my coreboot build (for the Thinkpad X230 in my case; has then revision "1f" and verified functionality using https://github.com/speed47/spectre-meltdown-checker or similar tools)
martin
So you are saying that sandy and ivybridge have spectre microcode updates?
I hate how unclear intel is about this.
How do I patch my coreboot?
So you are saying that sandy and ivybridge have spectre microcode updates?
I hate how unclear intel is about this.
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-upd...
Am 20.03.2018 00:15 schrieb Taiidan@gmx.com:
So you are saying that sandy and ivybridge have spectre microcode updates?
I hate how unclear intel is about this.
How do I patch my coreboot?
Like I said, the update is here for anybody to cherry-pick and test: https://review.coreboot.org/#/c/blobs/+/23315/
I expect this change to be merged sometime "soon", when reviewed.
Yes, they even updated sandybridge and ivybridge. (For those, you only need the first of those 4 patches)
Intel doesn't seem to care about informing users directly, at least this time around. They've worked with and for their "industry partners" and have left packaging updates to BIOS vendors. In the end we have a full release from Intel again though, so we're happy at last :)
martin
On 03/20/2018 04:17 AM, Martin Kepplinger wrote:
Yes, they even updated sandybridge and ivybridge. (For those, you only need the first of those 4 patches)
There are some of the last released high end xeon/core 771/775 CPU's getting updates in the future too.
Yeah I tried that but it didn't work.
git fetch https://review.coreboot.org/blobs refs/changes/15/23315/6 && git cherry-pick FETCH_HEAD
warning: no common commits remote: Counting objects: 555, done remote: Finding sources: 100% (30/30) remote: Total 1426 (delta 1), reused 1418 (delta 1) Receiving objects: 100% (1426/1426), 13.30 MiB | 4.21 MiB/s, done. Resolving deltas: 100% (396/396), done.
* branch refs/changes/15/23315/6 -> FETCH_HEAD error: could not apply 4f04985590... cpu: intel: microcode update for currently tracked models to 20180312 hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit
What do I do now? I have never used git before.
These patches need to be added stat - the stakes are too high for this to take months.
On 20.03.2018 22:25, Taiidan@gmx.com wrote:
Yeah I tried that but it didn't work.
git fetch https://review.coreboot.org/blobs refs/changes/15/23315/6 && git cherry-pick FETCH_HEAD
warning: no common commits remote: Counting objects: 555, done remote: Finding sources: 100% (30/30) remote: Total 1426 (delta 1), reused 1418 (delta 1) Receiving objects: 100% (1426/1426), 13.30 MiB | 4.21 MiB/s, done. Resolving deltas: 100% (396/396), done. From https://review.coreboot.org/blobs
- branch refs/changes/15/23315/6 -> FETCH_HEAD
error: could not apply 4f04985590... cpu: intel: microcode update for currently tracked models to 20180312 hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit
What do I do now? I have never used git before.
It's probably easier for you if you load the microcode update from your OS.
These patches need to be added stat
You obviously have no idea what you are talking about. 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.
- 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. 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.
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.
Nico
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.
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
Am 21.03.2018 11:13 schrieb Nico Huber:
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.
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
-
[799] -
Alberto Bursi -
awokd -
David Hobach -
Martin Kepplinger -
Merlin Büge -
Mike Banon -
Nico Huber -
Taiidan＠gmx.com -
Timothy Pearson