How will libreboot deal with Meltdown and Spectre?

13 risposte [Ultimo contenuto]
ollonois
Offline
Iscritto: 08/15/2016

The question I asked myself is how will libreboot project deal with Meltdown and Spectre security issues.
Mostly all libreboot users are using affected old core2 CPUs and regardless of whether libreboot is willing to implement microcode it is unlikely that Intel will ever release firmware updates for these old processors.
So from my point of view there is now way to create a free and secure system anymore apart from the 2 supported atom boards which seem not to be affected but do not offer great performance and are not usable as mobile devices.

Are there any ideas or solutions to deal with this problems?

Abdullah Ramazanoglu
Offline
Iscritto: 12/15/2016

> So from my point of view there is now way to create a free and secure system anymore

Given the closed architecture and microcode Intel/AMD/ARM CPU's have, was it possible to do that in the first place, i.e. before meltdown and spectre?

ollonois
Offline
Iscritto: 08/15/2016

In a certain way it was possible, as the older CPUs have no ME, but now the situation is even worse. These security issues make the core2 CPUs completely unusable.
Don't get me wrong. I know that this was not the perfect solution in terms of the dream of totally free hardware, but it was a the best and most practical solution available.

Abdullah Ramazanoglu
Offline
Iscritto: 12/15/2016

Then, by "freedom and security" you mean immunity to hackerdom, and not to instutional intelligence (Intel and various intelligence services they possibly cooperate with).

Because, with a proprietary µcode and architecture, all those CPU's were already compromised when they are first sold. Meltdown and spectre opens your system to hackers, but it was already open to Intel for years. And the µcode update libreboot might provide or not will not protect you against Intel (and their accomplices) but only against the hackers.

So the question is rather simple, really. Which is;

"Shall I continue to be open to just Intel et.al. (with µcode update), or shall I be open to *both* Intel and hackers (without µcode update)?"

Abdullah Ramazanoglu
Offline
Iscritto: 12/15/2016

> with a proprietary µcode and architecture, all those CPU's were already compromised

That is, with or without ME.

jxself
Offline
Iscritto: 09/13/2010

"Are there any ideas or solutions to deal with this problems?"

Yes: Don't worry about it. If you think on it you will see this is a problem specific to people that use proprietary software, that do their computing on other people's computers (what some like the call "the cloud"), or that randomly run third party programs that random people send into their browser. None of that, of course, is good from a "security" perspective right? Especially that last one. But some insist on doing it, and build up ever bigger ever stronger walls to defend against attacks, but ever bigger vulnerabilities are being detected too.

But they're doing it to themselves: If people don't do their computing in other people's computers (aka "cloud computing") they don't have to worry that some other customer might compromise the machine that powers their "shared cloud" by using meltdown or spectre. Similarly, if they don't run proprietary programs that they can never audit or trust what they're doing to be free of meltdown or spectre problems, and don't execute all programs that they're randomly given inside their web browser (since JIT engines used for JavaScript were found vulnerable to Spectre), what is the *real* risk at that point once those things are excluded?

I am reminded of an episode of Star Trek: The Next Generation called Hero Worship where they were also creating their own problem: https://www.youtube.com/watch?v=RHoXUP804vg

The solution was simple: Drop the shields. Just as here: Don't do those things.

It's good from both a "security" perspective and from a software freedom standpoint too.

onpon4
Offline
Iscritto: 05/30/2012

I agree with this 100%. There are so so so many bad things that are stopped by just not running code you can't trust on your computer.

ollonois
Offline
Iscritto: 08/15/2016

@jxself I do not agree with you and don' t think your solution is a solution that is practical.
The first thing is, that it is in my opinion a mistake to assume that only proprietary software can contain malicious code. You can also say disconnect your machine from the internet and you are safe.
The second thing is, that most sites in the internet are not useable without JavaScript. There may be people for whom it is enough to to use just the few sites that work without js or have open code.
But even if there is open source software you have to review the code every time before you execute it to be sure that it does no bad things.

jxself
Offline
Iscritto: 09/13/2010

"The first thing is, that it is in my opinion a mistake to assume that only proprietary software can contain malicious code."

Although that's not what I said now, was it? I referred to running "proprietary programs that they can never audit or trust." The difference being that, if someone were stupid enough to put something into a free program that makes use of the Spectre exploit, we here in the free world will make a modified version and remove it.

"you have to review the code every time before you execute it"

I don't know why this would necessarily have to be the case. I can't speak for other people's computers, but the software on my computers is not changing without my knowledge. So if I run a program and then come back to it 5 minutes later and run it again, it is the same program. Perhaps this could be a thing to consider when applying updates from someone's distro, but really only if someone's threat model included the notion that the distro might themselves ship them malicious programs. But the notion of the distro itself shipping such things is a separate matter. Such a thing would, of course, make news like Ubuntu did when they started sending local search terms out over the internet and help people question if they should even use that distro or not.

"The second thing is, that most sites in the internet are not useable without JavaScript."

You must be using a different internet than I do. If something can only be used with proprietary software and can't be used with free software then I question whether it should be used at all. But I understand that different people will come up with different answers to that because not everyone is willing to give up their proprietary software. But I digress because but this is a separate matter from finding ways to avoid Meltdown and Spectre. My original point remains. But, if someone were to absolutely insist "No! I must continue to deliberately cause these problems for myself", there are still other options too without having to resort to proprietary microcode changes. Someone could, for one possibility, have a physically separate machine dedicated to such things (preferably on a physically separate network) without any confidential stuff on it in case some program makes use of the Spectre exploit to grab it. And they always treat the machine as if it were root-compromised. But, as we see here, this would be part of the building up walls to defend against attacks that I was talking of earlier. It can be simpler to remove onesself from the situation in the first place, which is what I was originally talking about.

Of course I don't pretend these to be the only solutions for how someone might address the issues raised by Meltdown and Spectre without using proprietary software. Another might be using a computer with a CPU that doesn't have speculative execution. I think there was a thread here somewhere about that. Feel free to join in and help come up with more solutions. Solutions was what the original question was about anyway. ;)

SuperTramp83

I am a translator!

Offline
Iscritto: 10/31/2014

>javascript

Well, FF was patched for metdownz. You can also mitigate spectre by disabling jit in your browser - linky ->

https://trac.torproject.org/projects/tor/ticket/21011

*I can count the websites I allow javashit to run on the fingers of my left hand. You get used to it, get much faster browsing, safer and much much more functional - if a website requires js to display text and images I simply move over.

Ignacio.Agullo
Offline
Iscritto: 09/29/2009

On 08/02/18 09:08, wrote:
> So from my point of view there is now way to create a free and secure
> system

You got it wrong. It is "there is no way to create a free and
secure system", for Libreboot blocks all microcode updates. Librebooted
computers will be affected by Meltdown and Spectre forever.

--
Ignacio Agulló · name at domain

jxself
Offline
Iscritto: 09/13/2010

"Librebooted computers will be affected by Meltdown and Spectre forever."

We don't know that it's unsolvable, all we know is that the solution chosen by upstream relies on microcode changes.

I wonder if it would be possible to spark some community movement towards alternate mitigation measures that do not require microcode updates, even if sacrificing some performance.

afzal
Offline
Iscritto: 02/09/2018

[Upon researching to buy a FSF RYF certified hardware, a few of which were using Trisquel, reached here]

[avoiding if & buts at the risk of some of the below going wrong to keep the post simple, links are provided for more details]

W.r.t GNU/Linux Kernel on Meltdown & Spectre:
a. Meltdown has been fixed purely in software by 4.15 Kernel [1]
b. Spectre variant 2 fixes also went by 4.15 (note that this in addition requires the kernel to be built with compiler supporting "retpoline", GCC 7.3 has it), all pure software changes
c. Spectre variant 1 fixes is expected to be available by 4.16-rc1 (would probably be released by this weekend), again pure software changes

Weekly coverages on related Kernel development, see [2-4]

Now w.r.t (b), there is some confusion (for me), in one of the below lwn links it has been mentioned that to fix Spectre v2, there are 2 options, either microcode update (for IBRS) or using retpoline (except SkyLake). Linus T says [6] that it has been fixed with retpoline, but is seems there is more to it than he is aware, in the reply David W (who had been working on these patches) says that IBPB support is also required along with retpoline. IBPB & IBRS are features added by microcode update. And Greg KH [5] also says he needs to update microcode. So there appearance to be a difference in what Linus & LWN update says vs David W & Greg KH

So expect for the confusion on (b), other things are entirely handled in software.

[1] https://marc.info/?l=linux-kernel&m=151717638018350
[2] https://lwn.net/Articles/742702/
[3] https://lwn.net/Articles/742984/bigpage
[4] https://lwn.net/Articles/744039/bigpage
[5] http://kroah.com/log/blog/2018/01/19/meltdown-status-2/
[6] https://lwn.net/Articles/745112/
[7] https://lwn.net/Articles/745113/

afzal
Offline
Iscritto: 02/09/2018