Home > Hardware, Intel Atom, Intel Celeron, Intel Core, Intel Core M, Intel Pentium, Linux, Windows 10 > Intel Hardware Security Bug Fix to Hit Performance on Windows, Linux…

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

Orange Pi Development Boards

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.

  1. Sandbender
    January 3rd, 2018 at 13:20 | #1

    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.

  2. crashoverride
    January 3rd, 2018 at 16:31 | #2

    @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 also expect the increased IRQ service times to expose timing related issues in drivers since Linux is not deterministic (realtime).

  3. blu
    January 3rd, 2018 at 18:48 | #3

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

  4. Tomm
    January 3rd, 2018 at 19:33 | #4

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

  5. January 3rd, 2018 at 19:35 | #5

    @Tomm
    I don’t think that bug will be there yet (for any processor), as they are not ready to disclose all details yet.

  6. blu
    January 3rd, 2018 at 20:03 | #6

    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.

  7. tkaiser
  8. crashoverride
    January 4th, 2018 at 07:33 | #8

    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.

  9. Tomm
    January 4th, 2018 at 14:12 | #9

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

  10. January 4th, 2018 at 14:31 | #10

    @Tomm
    No problem, since Cortex A53 cores are not listed.

    Finally AMD is also impacted but to a lesser extent.
    https://www.cnx-software.com/2018/01/04/companies-address-concerns-related-to-speculative-execution-exploitations-in-processors-meltdown-and-spectre/

  11. sky770 (aka TheOldMonk)
    January 4th, 2018 at 15:08 | #11

    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 aspect which I am wondering and worried about..the damage it could inflict in financial & other delicate sectors…. 😐 now that it’s out there in the wild….unless they fix it in-design physically and implement the logical fix in software something which can only be optimized in the long term.

    Oh and I recently read it somewhere that Intel’s CEO dumped a lot of his shares..a common practice but he has exactly the minimum number of them right now as per company’s rule…interesting… but was bound to happen.

    Strange times indeed! 😀

  12. sky770 (aka TheOldMonk)
    January 4th, 2018 at 15:13 | #12

    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! 😀

  13. blu
    January 4th, 2018 at 16:08 | #13

    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.

  14. willy
    January 6th, 2018 at 13:57 | #14

    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.

  15. blu
    January 6th, 2018 at 18:14 | #15

    @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.

  1. No trackbacks yet.