The disclosure on the processor bugs [LWN.net]

Are POWER processors immune?

Posted Jan 3, 2018 22:40 UTC (Wed) by tarvin (guest, #4412) [Link] (20 responses)

IBMs POWER processors do not seem to be mentioned. I wonder if they have been investigated, and if so: whether they are immune, or not?

Are POWER processors immune?

Posted Jan 3, 2018 23:09 UTC (Wed) by tbodt (subscriber, #120821) [Link] (18 responses)

If it supports speculative execution in just about any form, it's vulnerable.

Are POWER processors immune?

Posted Jan 3, 2018 23:37 UTC (Wed) by arnd (subscriber, #8866) [Link] (1 responses)

I'm fairly sure that IBM z/Architecture (arch/s390) is immune because they already have a split page tables for user and kernel address spaces. IIRC sparc is similar to s390 here, but powerpc is like all the others and has kernel and user in the same address space.

Are POWER processors immune?

Posted Jan 4, 2018 0:10 UTC (Thu) by bboissin (subscriber, #29506) [Link]

Split tables are a fix for meltdown, arch may still be impacted by spectre, right?

Are POWER processors immune?

Posted Jan 4, 2018 0:30 UTC (Thu) by rahvin (guest, #16953) [Link] (15 responses)

What about the AMD submitted patch to add a flag disabling the page separation on AMD processors because they say they aren't affected?

https://lkml.org/lkml/2017/12/27/2

Was that premature or is AMD actually not vulnerable?

Are POWER processors immune?

Posted Jan 4, 2018 0:35 UTC (Thu) by roc (subscriber, #30627) [Link] (14 responses)

AMD has not been shown to be vulnerable to Meltdown. Ryzen is definitely vulnerable to Spectre, mainly because Spectre is a different and very general class of attack.

Are POWER processors immune?

Posted Jan 4, 2018 3:30 UTC (Thu) by rahvin (guest, #16953) [Link] (13 responses)

I"m trying to get a handle on these two attacks and their long term implications but I don't have a CS background. Meltdown appears to be more dangerous in that it allow arbitrary reads of any memory and easily but also the more prevalent, possibly in intel processors all the way back to the Pentium. Spectre is also a memory read problem but affects every processor, is hard to execute but at the same time is very difficult to patch out.

Spectre sounds more like a problem that's inherent to the design of the microprocessor/memory subsystem while Meltdown sounds like a logic error on intel processors. Do they both require the same fix with this kernel/user page separation that's being developed? Or is Spectre going to require a redesign of how cpu/memory is used and integrated throughout the industry to try to eliminate it and thus will be around as a problem for a long time? This is the feeling I've gotten from some of the reporting.

I'm looking for some input/explanation from people that can read the research and understand what it means in a long term perspective and put it in lay terms. The reporting has made spectre to be the kind of thing that's going to be generating vulnerabilities for ages because it's so fundamental.

Are POWER processors immune?

Posted Jan 4, 2018 6:34 UTC (Thu) by Wol (subscriber, #4433) [Link]

> I'm looking for some input/explanation from people that can read the research and understand what it means in a long term perspective and put it in lay terms.

Meltdown as I understand it is that it allows ring-3 (user) code to retrieve ring-0 (system) code into memory. This should not be possible, but a bug in Intel processors does not keep the ring status with code undergoing speculative execution. AMD doesn't suffer this bug. In other words, this is a hardware problem, and only new hardware will actually fix it.

KAISER is a work-around. By forcing (at some cost) kernel memory to be in a separate address space, the normal address-space protections kick in and ring-3 code no longer even knows that the kernel space exists, and so can't access it.

So Meltdown will be fixed, done, dusted very quickly at the software level, but take a lot longer at the hardware level. Existing Intel processors might not be a good buy any more...

To cut a long story short - meltdown is a bug so not all implementations are vulnerable, and the mitigation is simple if costly.

Spectre I currently know nothing about.

Cheers,
Wol

Are POWER processors immune?

Posted Jan 4, 2018 7:26 UTC (Thu) by roc (subscriber, #30627) [Link] (11 responses)

PTI doesn't affect Spectre at all.

Some specific Spectre attacks can be blocked. For example this "retpoline" thing (https://lkml.org/lkml/2018/1/3/770) is supposed to block speculative execution of indirect branch targets, which probably blocks attacks in section 5 of the Spectre paper and also one of the attacks described by Jann Horn of Project Zero (albeit at further, not yet measured, performance cost).

However, I haven't seen anyone talk about mitigating the Spectre attacks that leverage speculative execution of conditional branches. Blocking speculative execution of conditional branches would incur a severe performance penalty. Fortunately we don't yet have any PoC showing a Spectre-like attack against kernel conditional branches from user space, only (via Project Zero) from eBPF progams. But that doesn't mean they're impossible...

Blocking all classes of these attacks definitely requires hardware changes, although it's not clear exactly what those changes should be. These are a couple of instances of a general class of problem: leaking information across protection domains via non-architectural state read via timing channels.

> The reporting has made spectre to be the kind of thing that's going to be generating vulnerabilities for ages because it's so fundamental.

I agree with that assessment. I would definitely bet against these bugs being the last of their kind.

Are POWER processors immune?

Posted Jan 4, 2018 11:34 UTC (Thu) by nix (subscriber, #2304) [Link] (10 responses)

Well, there's one easy approach. Accurate reading of high-resolution timers must clearly be a privileged operation, since it leaks too much information about the internal operation of the processor to unprivileged users who have no right to see such things. I see no reason we can't pass something like high-res timers down to nonprivileged users, high-res for the first read or two but which go lower-res if you query them repeatedly in a short period of time. This screws some debugging and benchmarking uses: I think a root-flippable switch in /proc or something to allow userspace to query high-res timers unperturbed, or a prctl() only root can flip, or preferably both, would suffice. (A few things that need truly accurate high-res timers for internal timing, like X or PostgreSQL, might need to flip it in any case, but X has a privileged wrapper already and PostgreSQL has a specialized startup script that could gain appropriate magic, given suitable administrator permission.)

This seems really easy and obvious and incurs no performance hit, while only allowing root / root-with-appropriate-cap to read kernel memory any more (and frankly root can do anything in any case). I don't understand why the massive performance hit of KPTI was implemented instead (I mean, seriously, three or four mitigations of this expense and we won't have CPUs any more, they'll be spending all their time mitigating).

Are POWER processors immune?

Posted Jan 4, 2018 11:45 UTC (Thu) by excors (subscriber, #95769) [Link] (8 responses)

Couldn't attackers have a thread doing "volatile int timer; while (1) { timer++; }", and the main thread can simply read that variable? That's probably going to be pretty high resolution timer, especially if you've got hyperthreading so the value stays in L1 cache.

Are POWER processors immune?

Posted Jan 4, 2018 12:08 UTC (Thu) by steven676 (subscriber, #41893) [Link] (6 responses)

Indeed, that's exactly what the authors of the Meltdown paper did to get a high-res timer on Chrome, which does limit timer resolution via normal timing APIs.

Are POWER processors immune?

Posted Jan 4, 2018 22:14 UTC (Thu) by marcH (subscriber, #57642) [Link] (5 responses)

At the risk of stating the obvious, here's one dead (too) simple and... LWN-crowd pleasing solution: stop running code you can't audit the source code of. Not the same as open source but going into the same direction. Helps with *all* security issues. Spectre and other timing attacks = the beginning of the end for closed source?

On a different topic I wonder whether this class of attack could promote virtualization in future CPUs; I mean I wonder whether it is easier/cheaper/faster for the designer of some future CPU to block speculative accesses across VMs *only* compared to blocking *all* speculative accesses which are not authorized. Then each application gets a VM which is already happening in the cloud anyway.

Are POWER processors immune?

Posted Jan 5, 2018 1:24 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] (4 responses)

Certainly for some applications, you can isolate your machine(s) from the Internet, forbid anyone to run any services on it but your own compute-intensive application, and run at full speed with security measures off. But if you are a hosting company providing virtual machines of some form, using any container technology you please, it's your customers, not you, who will be choosing what source code to run, and they can break you with properly GPL-licensed exploit code. Likewise, if anyone can use a web browser you can write the attack in JavaScript, and the code doesn't even have to be obfuscated, because no one's going to read the code before they hit that page.

RMS once advocated not using passwords and letting everyone do anything (though he eventually gave up on that idea). That might have worked in 1980 at MIT with a small group of guru friends being the only people with access, but those days are gone. We have to deal with hostile code. And it's possible to slip cleverly disguised back doors into source code, the NSA has people who specialize in that.

Are POWER processors immune?

Posted Jan 5, 2018 1:52 UTC (Fri) by rahvin (guest, #16953) [Link] (2 responses)

Lets not forget how easy it is to obfuscate the code, even open source code to the point where no one can even tell it's doing something malicious. There are several yearly contests to demonstrate this capability so people don't get complacent. There are likely people at the NSA and every other national spy agency that have these kind of capabilities, which is exactly the reason most of these organizations don't trust code from other countries.

Are POWER processors immune?

Posted Jan 5, 2018 2:38 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

"This bullet is not silver. It only works most of the time so let's not use it."

Are POWER processors immune?

Posted Jan 5, 2018 9:03 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

For most organizations, "don't use programs you can't audit the source for" is "don't use computers". This bullet is not even silver-plated. The lead core was melted down directly from mediaeval church roofing without further refinement, so there's probably a little bit of silver inside.

NoScript

Posted Jan 9, 2018 20:50 UTC (Tue) by marcH (subscriber, #57642) [Link]

> Likewise, if anyone can use a web browser you can write the attack in JavaScript,

I never found that running random code from many random websites when merely searching for "passive" information was a good idea. When Javascript came up I used to fiddle with my browser settings to allow it on a per-site basis but that proved to tedious and limiting and I surrendered eventually. Maybe it's become easier and I should give it another try.

NoScript & co should certainly leverage the current media attention to promote themselves.

Are POWER processors immune?

Posted Jan 4, 2018 21:45 UTC (Thu) by nix (subscriber, #2304) [Link]

Oh damn I forgot that microcomputer-style infloop cycle counting existed :) age must be creeping up on me.

Are POWER processors immune?

Posted Jan 4, 2018 16:40 UTC (Thu) by zblaxell (subscriber, #26385) [Link]

> few things that need truly accurate high-res timers for internal timing, like X or PostgreSQL, might need to flip it in any case, but X has a privileged wrapper already and PostgreSQL has a specialized startup script that could gain appropriate magic, given suitable administrator permission.

That would mean you would break X or PostgreSQL running in an unprivileged guest context (e.g. kvm, xen, etc).

Are POWER processors immune?

Posted Jan 4, 2018 0:23 UTC (Thu) by corbet (editor, #1) [Link]

Red Hat seems to think that POWER processors are vulnerable too.

The disclosure on the processor bugs

Posted Jan 3, 2018 22:57 UTC (Wed) by post-factum (subscriber, #53836) [Link] (2 responses)

Has Google just broken that embargo which should last till Jan, 9th?

The disclosure on the processor bugs

Posted Jan 3, 2018 23:04 UTC (Wed) by makomk (guest, #51493) [Link]

I think the embargo was ended early after people independently figured out the nastier of the bugs and someone managed to reproduce it and tweet about it.

The disclosure on the processor bugs

Posted Jan 4, 2018 0:06 UTC (Thu) by smoogen (subscriber, #97) [Link]

It will depend on which step is considered first in line:
1. The Register article
2. The people looking at various patches in kernel trees and coming up with PoC then tweeting them.
3. The various blogs about the issue starting yesterday.
4. The linking of this to Intel by people making money off of the Intel selloff/AMD stock buy
5. The post by Intel after the market closed to explain that the problem was real and they were working to fix it.
6. Some other PoC's coming out
7. Google doing the announcement after all that.

The disclosure on the processor bugs

Posted Jan 4, 2018 0:02 UTC (Thu) by cesarb (subscriber, #6266) [Link] (4 responses)

While KPTI is a workaround for Meltdown, the following patch series seems to be a workaround for Spectre: https://www.spinics.net/lists/kernel/msg2688859.html

Patch 9 in that series mentions a gcc option, -mindirect-branch=thunk-extern, which I haven't seen anywhere else. Is that a Spectre workaround for gcc?

The disclosure on the processor bugs

Posted Jan 4, 2018 0:10 UTC (Thu) by rich0 (guest, #55509) [Link] (2 responses)

It mentions that a gcc patch to implement it is forthcoming.

Linus's reply was about as reserved as is typical: https://lkml.org/lkml/2018/1/3/797

non-exclusive-OR

Posted Jan 4, 2018 9:33 UTC (Thu) by Garak (guest, #99377) [Link]

Workarounds with performance penalties should have configuration options to disable them even if Intel never intends to fix anything. There should always be knobs saying "I want more speed from those engines Scotty, no matter how you do it". Security is not a requirement for all use-cases. Maybe not even most.

The disclosure on the processor bugs

Posted Jan 4, 2018 10:11 UTC (Thu) by AndreiG (guest, #90359) [Link]

Another gem from Linus !

As a former Intel enployee all I can say is:
Bwahahahaahhaahhaha !

The disclosure on the processor bugs

Posted Jan 4, 2018 0:45 UTC (Thu) by roc (subscriber, #30627) [Link]

That series only addresses some of the Spectre issues.

The general problem of supposed-to-be-hidden CPU state actually being observable, with data leaking across protection domains via that supposed-to-be-hidden CPU state, is massive.

silver lining?

Posted Jan 4, 2018 1:48 UTC (Thu) by astian (guest, #118981) [Link]

I'm looking forward to seeing hardware liberated by applying these techniques.

Cache invalidate

Posted Jan 4, 2018 2:14 UTC (Thu) by iive (guest, #59638) [Link] (2 responses)

About Meltdown,

Would invalidating the cache as first step at protection exception handling be useful to hide the data leak?
At very least it should make the time window for reading the flag a lot shorter, thus less reliable.
How short depends on a lot of CPU details...

If I understand correctly... you use two processes. One constantly checks pre-defined memory location(s) by timing the read operation at them (and clearing their cache lines). If a location is read with very small delay, it has been cached by another process. That process is receiving information, bit by bit.
A sender process uses speculative execution to load into a register a protected (kernel) data and use the register value to read one of the pre-defined memory locations (and load them into the cache).
The CPU discovers the protection error and discards the register, but cache is kept.

Cache invalidate

Posted Jan 4, 2018 7:31 UTC (Thu) by roc (subscriber, #30627) [Link] (1 responses)

Your understanding is basically correct but you don't necessarily need two processes, the same process could do both functions.

Invalidating the cache on a protection fault wouldn't work. The main Meltdown approach described in the paper doesn't actually generate protection faults (see "fault suppression", section 6.2.2).

Cache invalidate

Posted Jan 5, 2018 23:57 UTC (Fri) by iive (guest, #59638) [Link]

There are basically 3 ways to avoid termination.

1. Exception handling by handling the segmentation fault signal. If we cause exception and then handle it in the same process/thread, then cache invalidation would completely mitigate the problem.
You will need two processes/threads concurrently running in order for the receiver process to be able to read the cache flags before the exception handler flushes all caches.

2. Intel TXR. This is new feature to execute code as transaction, so an exception just fails the transaction, without triggering protection violation. This feature is relatively new and has already been disabled on Haswell CPU (that were the first to have it) due to an implementation bug.
Disabling it again on all meltdown affected CPU is entirely possible workaround.

3. Hiding the kernel read under mispredicted branch. This never triggers protection violation, because the code should have never been executed.
That one is more similar to the Spectre attack.

In all cases, reading a valid value from kernel data should not have been possible.

The disclosure on the processor bugs

Posted Jan 4, 2018 6:06 UTC (Thu) by shemminger (subscriber, #5739) [Link]

The POC use eBPF and JIT which may also no longer be considered safe.

ASLR?

Posted Jan 4, 2018 19:33 UTC (Thu) by joey (guest, #328) [Link]

From the Spectre paper:

The algorithm that tracks and matches jump histo- ries appears to use only the low bits of the virtual address (which are further reduced by simple hash function). As a result, an adversary does not need to be able to even execute code at any of the memory addresses containing the victim’s branch instruction. ASLR can also be compensated, since upper bits are ignored and bits 15..0 do not appear to be randomized with ASLR in Win32 or Win6

I think ASLR on Linux also doesn't randomize those bits of the address currently. But, could it be made to randomize everything except the low byte without causing alignment problems, and so guard against Spectre?