How safe is it to ignore spectre(retpoline) patches ?

sarfaraz1989 · 2018-02-26 18:24:55

Hi,
I was wondering how hard is it to hack using spectre vulnerability. I have an old sandybridge laptop and I feel that retpoline patches that now in place in the kernel/gcc/applications have taken a toll on the performance. I constantly hit high temperatures and performance is somewhat sluggish. I dual-boot with an older unpatched linux distribution and with the same workload(and nearly the same set of processes), the laptop is much smoother and less hot.

I understand there has been some cleanup for spectre/meltdown in upcoming linux 4.16 kernel that would help in some manner with the performance trade-off.
If you all could share your experiences/decisions that would be nice.

frostschutz · 2018-02-26 18:48:43

I was wondering how hard is it to hack using spectre vulnerability.

It would be easy - if it worked in JavaScript, as that is unchecked code running on every site you visit. But that's just the thing, I've yet to see a working demo for that.

Until then, I'm not particularly worried. For single user systems, I'm fine with disabling the patches. It's very different if you have customers running arbitrary code...

Or if you're using proprietary code like games... then again they don't even need any CPU bugs to do harmful stuff. Like that flight simulator that grabbed people's password manager data.

Last edited by frostschutz (2018-02-26 18:53:56)

Trilby · 2018-02-26 19:20:27

frostschutz wrote:

Or if you're using proprietary code ...

Being prorpietary doesn't make it more likely to be malicious. In fact I could argue the opposite: if you buy a piece of software, the authors have a financial liability in doing anything unethical with it.

Sure with open source software you can read the code yourself. But do you? Have you carefully read the code for every tool, plugin, and add-on you use? Could one person even read and understand all the code of a modern browser? Have you even thoroughly read the code for xinit? (I mention this one as I doubt that anyone who has would continue to use it).

The fact that fork-bombs even exist suggest that many users don't even glance at scripts let alone source code for big programs.

I read the titular question here like asking how safe it is to not use a seat belt and disable the air bags in your vehicle. A vast majority of the time absolutely no harm would come from it. But you would not survive one exception to this pattern.

Last edited by Trilby (2018-02-26 19:23:03)

frostschutz · 2018-02-26 20:00:17

Trilby wrote:

But do you?

Sometimes. And in the end, it's code that already runs with user, or even root permissions. Obscure CPU bugs are very irrelevant at that point.

Not to mention, once you control the system, you can disable those patches yourself anyhow. To the Linux kernel, this is a simple boot flag.

The interesting aspect of this CPU bug is that it crosses boundaries. One user to another user account. One virtual machine to another or even to the host.

— Isolated JavaScript from inside the browser to the desktop. That would be the kicker. But I've seen no proof of concept for that. All programs that test whether you are vulnerable or demonstrate it, are things you download and run locally, there is no site that tests Meltdown/Spectre in browser that I know of.

Also while on the topic of reading code, that's the fun part with CPU bugs: the code is perfectly harmless. Just by looking at the code, there is nothing to see. It's code that just looks at zeroes, beautiful zeroes. It's the CPU doing the wrong things and turns those zeroes into data you shouldn't have any access to. CPU doing things that aren't in the code at all.

Trilby wrote:

how safe it is to not use a seat belt and disable the air bags in your vehicle.

A sports car (or even a regular car) is certainly much safer if you limit it to the speed of a tractor. Even so, most people won't reduce their car's maximum speed.

Now we have a patch that reduces the PC speed drastically (by adding several tons of insane overhead), the CPU runs hotter doing less work, machines crash due to shoddy microcode updates, data is lost ... these so-called fixes have caused more damage than known exploits did at this point ... and all because of what is - to a single user system - a very theoretical threat.

Ransomware existed before this bug and will still exist after it. Real vulnerabilities are elsewhere.

Last edited by frostschutz (2018-02-26 20:08:03)

loqs · 2018-02-26 20:20:30

sarfaraz1989 wrote:

I understand there has been some cleanup for spectre/meltdown in upcoming linux 4.16 kernel that would help in some manner with the performance trade-off.

Almost all the patches from 4.16 for spectre have already been backported to 4.15 and 4.14 at least. When intel introduces a microcode update for sandybridge providing IBPB
that will decrease performance in cases where it is used such as a context switch to a process that is marked none dumpable. V1 mitigation as far as I am aware is always
enabled. Userspace built with mindirect-branch=thunk would similarly have mitigation permanently enabled.
edit:
IBPB not IBPP

Last edited by loqs (2018-02-26 20:21:49)

cirrus9 · 2018-02-27 23:22:57

I have a Sandybridge CPU in my desktop machine, and I don't really see much difference in performance, load, or temps. I will be very surprised if Intel ever comes out with a microcode update for any of these older CPU models. Unless performance gets much worse in the future, I'm not going to disable any of the spectre mitigations. Nobody really knows what hackers are doing, or have done with this.

loqs · 2018-02-27 23:31:16

@cirrus9 see https://newsroom.intel.com/wp-content/u … idance.pdf microcode update status beta.

R00KIE · 2018-02-28 14:10:36

I'd say that unless you can access very well if you can disable the protections you should leave them on, specially if you run a browser in a machine with internet connection.

There are many ways untrusted code can run in a browser and now that the cat is out of the bag I'm sure sooner or later someone will find a way to exploit these problems.

That said, from what I can understand, right now only the kernel is well protected and you want the kernel to be well protected, other programs need to be recompiled with extra gcc/llvm flags and even so I'm not sure that will be enough, I suspect some code changes will have to be made.

loqs · 2018-03-14 01:59:43

20180312 microcode update includes updates for older platforms such as Sandybridge.
As a note if you manually update the 20180108 PKGBUILD if you run updpkgsums the ';' from the end of the sha256sums array will truncate the PKGBUILD to end with the ';' producing an empty package.

Arch Linux

#1 2018-02-26 18:24:55

How safe is it to ignore spectre(retpoline) patches ?

#2 2018-02-26 18:48:43

Re: How safe is it to ignore spectre(retpoline) patches ?

#3 2018-02-26 19:20:27

Re: How safe is it to ignore spectre(retpoline) patches ?

#4 2018-02-26 20:00:17

Re: How safe is it to ignore spectre(retpoline) patches ?

#5 2018-02-26 20:20:30

Re: How safe is it to ignore spectre(retpoline) patches ?

#6 2018-02-27 23:22:57

Re: How safe is it to ignore spectre(retpoline) patches ?

#7 2018-02-27 23:31:16

Re: How safe is it to ignore spectre(retpoline) patches ?

#8 2018-02-28 14:10:36

Re: How safe is it to ignore spectre(retpoline) patches ?

#9 2018-03-14 01:59:43

Re: How safe is it to ignore spectre(retpoline) patches ?

Board footer