Intel Hardware Security Bug Fix to Hit Performance on Windows, Linux…

Many security bugs can be fixed without performance penalty , but according to reports Intel processors have a hardware bug – whose details have not been disclosed yet (embargo) – that seems to affect all operating systems including Windows, Linux, Mac OS, etc…, and the fix may lead to significant performance hits for some tasks.

We know a bit more thanks to the Kernel Page Table Isolation (KPTI) patch for Linux that enables the fix/workaround with X86_BUG_CPU_INSECURE feature. The fix used to be called KAISER, and there’s an explanation on LWN about “hiding the kernel from user space” about the issue:

On contemporary 64-bit systems, the shared address space does not constrain the amount of virtual memory that can be addressed as it used to, but there is another problem that is related to security. An important technique for hardening the system is kernel address-space layout randomization (KASLR), which randomizes the placement of the kernel in the virtual address space at boot time. By denying an attacker the knowledge of where the kernel lives in memory, KASLR makes many types of attack considerably more difficult. As long as the actual location of the kernel does not leak to user space, attackers will be left groping in the dark.

The problem is that this information leaks in many ways….

More recently, a concerted effort has been made to close off the direct leaks from the kernel, but none of that will be of much benefit if the hardware itself reveals the kernel’s location. And that would appear to be exactly what is happening.

This paper from Daniel Gruss et al. [PDF] cites a number of hardware-based attacks on KASLR. They use techniques like exploiting timing differences in fault handling, observing the behavior of prefetch instructions, or forcing faults using the Intel TSX (transactional memory) instructions. There are rumors circulating that other such channels exist but have not yet been disclosed…

and the fix:

Fixing information leaks in the hardware is difficult and, in any case, deployed systems are likely to remain vulnerable. But there is a viable defense against these information leaks: making the kernel’s page tables entirely inaccessible to user space. In other words, it would seem that the practice of mapping the kernel into user space needs to end in the interest of hardening the system.

The paper linked above provided an implementation of separated address spaces for the x86-64 kernel; the authors called it “KAISER”, which evidently stands for “kernel address isolation to have side-channels efficiently removed”. This implementation was not suitable for inclusion into the mainline, but it was picked up and heavily modified by Dave Hansen.

So in short, Intel processors leak the kernel’s location, so now efforts have to be made to close this hole at the OS level since the current hardware or microcode can be updated to fix this issue. In theory, having a fix in the operating system should be good enough, but there’s a caveat: performance hit!

Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.

and from The Register article linked above:

So PostgreSQL SELECT command is about ~20% slower with KPTI workaround, and I/Os in general seem to be impacted negatively according to Phoronix benchmarks especially with fast storage, but not gaming performance, Linux kernel compilation, H.264 encoding, etc…

However, if you own an AMD system you can do a victory dance since the processors are not affected, so the “fix” is disabled:

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set.

The Intel bug will be fully revealed later this month after all main OS have been patched, and I’d assume Intel will fix the hardware in its processors too, so we’ll live in interesting times when people may/will want to check the CPU revision / stepping number before purchasing an Intel system.

Support CNX Software - Donate via PayPal or become a Patron on Patreon
Advertisements
Subscribe
Notify of
guest
15 Comments
oldest
newest most voted
Sandbender
Sandbender
2 years ago

Unfortunately, it seems some (most/all?) ARM64 platforms are affected by the same general issue as well. (Note: KAISER is the name of the patchset to handle this issue… although some much more clever and profane ones have been proposed on the kernel mailing list.) Given how far behind the mainstream kernel a lot of vendors are this could be a sore point for IoT devices for a long time to come.

crashoverride
crashoverride
2 years ago

@Sandbender Unlike x86, ARM cores are configurable by the licensee. The Register article implies this exploit depends on speculative execution of instructions that complete before a page fault occurs. If an ARM design is not using speculative execution or the licensee has otherwise modified it (Apple?), then it may be unaffected. I expect this to hit server hardware the hardest. The patch adds extra overhead for every kernel context switch. In addition to SYSCALL, all IRQs also cause a context switch to service. Therefore, the more IO to devices a machine does, the greater the performance hit (in theory). I… Read more »

blu
blu
2 years ago

@crashoverride
Add to IO and IRQ VM page handling – overcommits will suddenly become way more costly..

Tomm
Tomm
2 years ago

Gemini Lake not on Intel security page list? What is different from rest?

blu
blu
2 years ago

Missing performance considerations on ARM aside, the greatest impact this will have on ARM from my perspective, is this change:

perf: arm_spe: Disallow userspace profiling when arm_kernel_unmapped_at_el0()

as users will have to boot into ‘insecure’ mode to be able to properly profile.

tkaiser
tkaiser
2 years ago
crashoverride
crashoverride
2 years ago

ARM has released cores affected:
https://developer.arm.com/support/security-update

They state “Only affected cores are listed, all other Arm cores are NOT affected.”. Of interest is that Cortex-A7 and Cortex-A53 are NOT listed. My guess is that these “slow” cores do not perform speculative execution.

Tomm
Tomm
2 years ago

What about Raspberry Pi 3? Cortex-A53 + Raspbian is on 32-bit?

sky770 (aka TheOldMonk)
sky770 (aka TheOldMonk)
2 years ago

Google rolled out the fixes on Pixel series in the security patch dated 05 Jan 2018. Official communication from Google stated that those patches contained Spectre and/or Meltdown fixes. Soon after installing the update users complained about “freezing”; an official communication over that confirmed that it’s because those users side-loaded the OTA update and is not affecting OTA users (which I came across so far is not that accurate). All in all, the fixes for both the issues will have a definite performance impact (looking at you Intel/ARM; AMD is only affected by 1 of these issues); it’s the security… Read more »

sky770 (aka TheOldMonk)
sky770 (aka TheOldMonk)
2 years ago

tkaiser :
Now this makes sense
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

just saw your comment..after posting mine
yeah that x guy! 😀

blu
blu
2 years ago

The really surprising moment for me in this entire reveal is that A53 is not affected by Spectre. That indicates A53 has substantially low levels of speculation, while achieving the good IPC it does.

willy
willy
2 years ago

blu :
The really surprising moment for me in this entire reveal is that A53 is not affected by Spectre. That indicates A53 has substantially low levels of speculation, while achieving the good IPC it does.

It basically shows the level of performance one can expect without speculative execution.

blu
blu
2 years ago

@willy
There’s hardly a CPU today that does not speculate one way or another. And A53 surely speculates (e.g. it has a branch predictor). Those that speculate the most are most susceptible to attacks like Spectre, of course. That does not mean that aggressively-speculating designs cannot be immune to particular side-channel attacks, if somebody put deliberate counter-measures in the design.

Advertisements