CPU Security Flaws MELTDOWN and SPECTRE

I've been reading up on this today. The rate at which the big names are patching and the fact that linux kernels are being back-patched is certainly alarming.

Could we have a better thread title?

 

I'm having some difficulty in determining from these preliminary stories which issue is which.
The initiating KAISER changes for Linux (there is some kind of page table separating in Windows underway as well, I think) are a mitigation for side-channel attacks related to evicting cache lines containing page table entries for OS functions whose locations in memory were supposed to be hidden by address space layout randomization. If done correctly, evicting entries from the TLBs would show which areas a given function had been placed.

Dynamic TLB timing behavior is not unique to Intel or x86 necessarily, and given its central role in virtual memory and possibly some kind of undisclosed reason for urgency, the fix to keep kernel space randomization useful would have a lot of high-level names involved. The change creates a split where the OS maintains a privileged version of the process' page tables, and a guest version for non-privileged mode in the same address space that doesn't have kernel pages mapped as well.
Until the timing attack was discovered, having both spaces mapped together saved performance while the existing infrastructure would stop any unauthorized usage. Part of those changes is a measure to prevent flushing the TLBs completely when changing modes, which is expensive for everyone.

I thought this next concern might have something to do with this not being sufficient in Intel's architectures to avoid the side channel attack, unless the TLB is flushed more fully and expensively. Some discussion points to this possibly being related to Intel's speculative behavior being more aggressive about pulling page entries into the TLBs, and thus reintroducing the side-channel attack. By default, this may be a problem that makes Intel as secure (insecure?) as it was prior to the initial changes, but the whole raft of changes for KAISER isn't just for Intel.

Perhaps more detail on will come out that makes the issue more clear.

 

I poked around a bit more about some of the references, and I think part of the distinction I missed earlier is that the proof of concept for the Linux changes is centered around a class of access faults where accesses are determined to be invalid based on permissions checks on entries already pulled into the TLB, rather than purely based on timing analysis.
The paper on side channel attacks for TLBs did have a cache preloading exploit AMD chips are not immune to, but the KAISER proposal doesn't cover that one.

The three exploits cited have Intel-specific elements or behaviors AMD's TLBs do not have. TSX, which AMD does not currently support, can fail due to permissions checks in a manner that is readily measured, and Intel's handling of prefetches to privileged locations and faults due to permission checks appear to leverage Intel's virtual memory system loading data into the TLBs first, then checking permissions. I didn't look enough to know what results there could be for Via, for those that may encounter them.

AMD's speculative behavior apparently quashes allocating translation entries until after permissions checks, which combats the strongest exploits, if not all of them.
ARM's tracking of kernel and client space is architecturally separate, which the KAISER changes are an attempt at emulating in a non-debilitating fashion.

Linux does extend to other architectures, although if they don't have the same level of hardware assist or awkwardly linked memory spaces the changes may not be applicable.

edit: Initial paper https://gruss.cc/files/kaiser.pdf

 

Is this a new exploit of some sort, or a continuing discussion of the management processor flaws from a few weeks ago? Because, I can't find any news coverage of any new, serious intel processor security flaw... (Is news not in mainstream circulation yet/being covered up so that patches have time to be deployed maybe?)

 

I'm not certain if the side-channel attacks are the only items addressed with the Linux change, or if that's related what the supposed undisclosed major flaw, if there is one.
I had skimmed through some of the research disclosures about side channel exploits related to page translation and other caches/buffers some time ago, which is why it didn't click with me why it was raising a furor now if that's what the rumors are about.
KASLR is more common now, but it's a nearly last line line of defense and not every implementation uses it, like the early jailbreak for the PS4 showed.
While AMD indicates their implementations do not allow accesses to hop privilege levels and invoke the TLB hardware, it's possible there's some other less obvious issue that didn't attract attention.

If it is the ASLR double fault exploits, I'm not sure if it's a bug as much as an undefined portion of the spec that is weak in a security angle that hadn't been thought of back when x86 decided on its architectural page tracking and hardware-managed translations. Perhaps AMD had some foresight on security, back when the first speculative x86 CPUs were designed, or I suspect it was for other reasons that their cores didn't speculate past certain page faults.

Given time to code more workarounds, the headline-grabbing numbers may see improvement.

 

17-23% performance hit

Great news for the upcoming 12mm RyZen launch
Bets on many reviews using pre-KPTI patch OS versions 'to fairly represent the real CPU performance'?

 

Only if they exclude AMD CPUs from the patch changes.

 

What about Windows? Will MS exclude AMD from the changes?

 

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

I'm sure many tech journalists are working on articles, gathering information etc. I know Anandtech are working on something.

 

Though do bear in mind that there's not much of value to be said until the actual exploit information and the complete patches are released. Good reporting is based on having all the facts.

 

Surely any change would be in the hardware specific code section which already exists?
Why would they make a performance hurting security kludge to an architecture which is not vulnerable to the flaw in question? (assuming that it truly is not vulnerable).

Games or not, surely a bunch of the sort of benchmarks used in CPU launch reviews will be affected.

 

There's a parallel effort to isolate kernel mappings from userspace in ARM64, and the ever mutable RISCV has a proposal for an architectural revision to counter the same kind of problem. There are architectures that have a hard split between kernel and user accesses, which is a barrier to crafting user code that can prod an invalid access that reveals behavior related to the kernel space.

However, at least some of the problems cited for Intel aren't applicable to ARM, but the overall concept is still considered useful in other ISAs. Perhaps with the NDA lift there is a more complete description that can really say whether AMD wouldn't find the change helpful at all?

 

Even games making heavy use of "virtual machine" DRM like the recent assassins creed for example? The cpu load was supposedly around 30 to 40%, how much would the performance loss be after MS patches windows, also, will they patch windows 7?

 

The AMD guy is pretty adamant.
His suggested code is literally IF Vendor ID != AMD THEN Force 'CPU Insecure mode'