Wednesday, January 3rd 2018

AMD Struggles to Be Excluded from Unwarranted Intel VT Flaw Kernel Patches

Intel is secretly firefighting a major hardware security vulnerability affecting its entire x86 processor lineup. The hardware-level vulnerability allows unauthorized memory access between two virtual machines (VMs) running on a physical machine, due to Intel's flawed implementation of its hardware-level virtualization instruction sets. OS kernel-level software patches to mitigate this vulnerability, come at huge performance costs that strike at the very economics of choosing Intel processors in large-scale datacenters and cloud-computing providers, over processors from AMD. Ryzen, Opteron, and EPYC processors are inherently immune to this vulnerability, yet the kernel patches seem to impact performance of both AMD and Intel processors.

Close inspection of kernel patches reveal code that forces machines running all x86 processors, Intel or AMD, to be patched, regardless of the fact that AMD processors are immune. Older commits to the Linux kernel git, which should feature the line "if (c->x86_vendor != X86_VENDOR_AMD)" (condition that the processor should be flagged "X86_BUG_CPU_INSECURE" only if it's not an AMD processor), have been replaced with the line "/* Assume for now that ALL x86 CPUs are insecure */" with no further accepted commits in the past 10 days. This shows that AMD's requests are being turned down by Kernel developers. Their intentions are questionable in the wake of proof that AMD processors are immune, given that patched software inflicts performance penalties on both Intel and AMD processors creating a crony "level playing field," even if the latter doesn't warrant a patch. Ideally, AMD should push to be excluded from this patch, and offer to demonstrate the invulnerability of its processors to Intel's mess.
Source: Phoronix Forums
Add your own comment

142 Comments on AMD Struggles to Be Excluded from Unwarranted Intel VT Flaw Kernel Patches

#51
Assimilator
OMG IT'S A CONSPIRACY!!!!!!11111111oneoneone

No, it's not. There is no guarantee that AMD CPUs are immune to this flaw, other than a claim from an AMD employee. That points to one of two scenarios:

a) Linux kernel devs have done their own testing and determined that AMD CPUs are, in fact, vulnerable (perhaps not in the same way as Intel's)
b) Linux kernel devs are simply being paranoid/prudent considering the severity of this issue, and will disable PTI for AMD CPUs in a subsequent release once they're certain AMD's chips are not vulnerable

There are literally zero valid reasons for anyone doing Linux kernel development to penalise AMD/prefer Intel; it would destroy their reputation. Similarly, if Intel was leaning on the kernel devs to do this, it would hurt their reputation.

"eidairaman1 said:
Intel has been trying to hide these flaws for 10+years now.
Seriously? Where is your goddamn proof? You're shitposting in this thread like it's going out of style, claiming everyone and their mother are Intel fanboys, yet it's you who's throwing unverified accusations around like confetti.

Adults are talking. Sit down, and be quiet.
Posted on Reply
#52
Vya Domus
"Assimilator said:
OMG IT'S A CONSPIRACY!!!!!!11111111oneoneone

No, it's not. There is no guarantee that AMD CPUs are immune to this flaw, other than a claim from an AMD employee. That points to one of two scenarios:

a) Linux kernel devs have done their own testing and determined that AMD CPUs are, in fact, vulnerable (perhaps not in the same way as Intel's)
b) Linux kernel devs are simply being paranoid/prudent considering the severity of this issue, and will disable PTI for AMD CPUs in a subsequent release once they're certain AMD's chips are not vulnerable

There are literally zero valid reasons for anyone doing Linux kernel development to penalise AMD/prefer Intel; it would destroy their reputation. Similarly, if Intel was leaning on the kernel devs to do this, it would hurt their reputation.
Pure speculation.
Posted on Reply
#53
eidairaman1
The Exiled Airman
"Assimilator said:
OMG IT'S A CONSPIRACY!!!!!!11111111oneoneone

No, it's not. There is no guarantee that AMD CPUs are immune to this flaw, other than a claim from an AMD employee. That points to one of two scenarios:

a) Linux kernel devs have done their own testing and determined that AMD CPUs are, in fact, vulnerable (perhaps not in the same way as Intel's)
b) Linux kernel devs are simply being paranoid/prudent considering the severity of this issue, and will disable PTI for AMD CPUs in a subsequent release once they're certain AMD's chips are not vulnerable

There are literally zero valid reasons for anyone doing Linux kernel development to penalise AMD/prefer Intel; it would destroy their reputation. Similarly, if Intel was leaning on the kernel devs to do this, it would hurt their reputation.



Seriously? Where is your goddamn proof? You're shitposting in this thread like it's going out of style, claiming everyone and their mother are Intel fanboys, yet it's you who's throwing unverified accusations around like confetti.

Adults are talking. Sit down, and be quiet.
If you would read several links throughout tpu relating to this issue you will see such. By the way I never said anyone was a fanboy, you did. You can't stand the fact Intel was caught in a lie and now the truth of their lies and corruption is coming out now.
So you need to get your fingers off the keyboard and let the adults discuss here instead of you trying to attack members with your baseless and stupid comments.

The reason you don't like what I write is because you can't see the light of truth.
BY THE WAY I'M SORRY MY COMMENTS IRRITATE YOU SO MUCH @Assimilator!
...NOT! DON'T LIKE ME PUT ME ON IGNORE!


By the way welcome to the ignore list
Posted on Reply
#54
Assimilator
"Vya Domus said:
Pure speculation.
As are the conspiracy theories in this thread. My speculation, however, is founded on knowledge of computer hardware and security best practices, as opposed to "INTEL IS TEH EVIL".

Your move.

"eidairaman1 said:
If you would read several links throughout tpu relating to this issue you will see such, so you need to get your fingers off the keyboard and let the adults discuss here instead of you trying to attack members with your baseless and stupid comments.

BY THE WAY I'M SORRY MY COMMENTS IRRITATE YOU SO MUCH @Assimilator!
...NOT! DON'T LIKE ME PUT ME ON IGNORE!


By the way welcome to the ignore list
Remind me, which one of us is making the hysterical claim that "Intel has been trying to hide these flaws for 10+years now", and therefore has the responsibility to provide proof to substantiate said claim?

Oh right, it's you.
Posted on Reply
#55
Parn
nix kernels are open source. I wonder why AMD don't just compile and release their own replacement kernel if their requests have been ignored by those kernel developers.

Do Windows kernels have the same patch? If so, I will make sure my home 2012 R2 server running hyper-v do not apply for the update.
Posted on Reply
#56
eidairaman1
The Exiled Airman
"Assimilator said:
As are the conspiracy theories in this thread. My speculation, however, is founded on knowledge of computer hardware and security best practices, as opposed to "INTEL IS TEH EVIL".

Your move.



Remind me, which one of us is making the hysterical claim that "Intel has been trying to hide these flaws for 10+years now", and therefore has the responsibility to provide proof to substantiate said claim?

Oh right, it's you.
The proof is in the pudding buttercup, do the search in tpu and it shall be revealed to you. By the way don't like me put me on ignore snowflake
Posted on Reply
#57
Assimilator
"Parn said:
nix kernels are open source. I wonder why AMD don't just compile and release their own replacement kernel if their requests have been ignored by those kernel developers.
That would be a major PITA since they would have to maintain a kernel build for every version of every distro. And most people who don't want to mess around with compiling their own kernel, also probably don't want to mess around getting kernel binaries from non-official distro sources. Much easier to just boot your kernel with the -nopti flag if you are running AMD/really don't want PTI enabled.

On the flipside, the majority of people and companies that actually care enough about PTI's performance impact to want it disabled, are probably already building their kernels from source - so they'll just turn it off at compile time.
Posted on Reply
#58
eidairaman1
The Exiled Airman
"Parn said:
nix kernels are open source. I wonder why AMD don't just compile and release their own replacement kernel if their requests have been ignored by those kernel developers.

Do Windows kernels have the same patch? If so, I will make sure my home 2012 R2 server running hyper-v do not apply for the update.
This will roll to Windows at some point. I would honestly put a safeguard up
Posted on Reply
#59
Peter1986C
"Parn said:
nix kernels are open source. I wonder why AMD don't just compile and release their own replacement kernel if their requests have been ignored by those kernel developers.
Linux distributors possibly rather leave the patch enabled for all on X86(-64) until it is cleared up whether it's necessary (better safe than sorry). And Linux distributors get the kernel from the Linux Foundation, not from AMD/Intel.
"eidairaman1 said:
The proof is in the pudding buttercup, do the search in tpu and it shall be revealed to you. By the way don't like me put me on ignore snowflake
Dude, take a breath. :)
Posted on Reply
#60
eidairaman1
The Exiled Airman
"Peter1986C said:
Dude, take a breath. :)
Tell that to Assimilator
Posted on Reply
#61
ShurikN
Don't have a doubt in my mind Intel pulled some underhanded move directly from "Intel's sleazy playbook of anti-consumerism". It's in their blood after all.
Posted on Reply
#62
jigar2speed
"Assimilator said:
OMG IT'S A CONSPIRACY!!!!!!11111111oneoneone

No, it's not. There is no guarantee that AMD CPUs are immune to this flaw, other than a claim from an AMD employee. That points to one of two scenarios:

a) Linux kernel devs have done their own testing and determined that AMD CPUs are, in fact, vulnerable (perhaps not in the same way as Intel's)
b) Linux kernel devs are simply being paranoid/prudent considering the severity of this issue, and will disable PTI for AMD CPUs in a subsequent release once they're certain AMD's chips are not vulnerable
.
You need to keep quiet sometimes. (we know you hate AMD) The new patch is already out that excludes AMD CPUs.

<a href="https://www.reddit.com/r/hardware/comments/7nr7dy/_/ds46kfe" target="_blank" rel="nofollow">hardware/comments/7nr7dy/_/ds46kfe</a>

<a href="https://www.reddit.com/r/hardware/comments/7nqy3h/_/ds42kks" target="_blank" rel="nofollow">hardware/comments/7nqy3h/_/ds42kks</a>
Posted on Reply
#63
RCoon
Gaming Moderator
I'm handing out reply bans if you guys don't calm the hell down. You're adults. Act like it. Use the ignore functionality if a member makes you botty-bothered. I came back from the new year with over a hundred report alerts because people are dead set on acting like they have the mental capacity of a parsnip.

Things people forget about this forum:
1. This is the internet. Thick skin is required.
in contrast;
2. You are free to post whatever you want. You are not free of the consequences of those posts. I'm very much free to implement said consequences.
Posted on Reply
#64
EarthDog
This... is bad for cloud and datcenters. However any decently planned cloud provider has mkre than ample headroom to absorb a 30% hit if it gets that high (not that it is ok...at all. Just saying it can be mitigated). I dont have my head completely wrapped around the issue, admitedly.

That will be the only thing i post on the subject at tpu. The maturity level in this forum, and what ive seen in this thread, hit an all time low. Every day it gets more difficult to have adult conversations with people at this forum... its like the kids table at the holidays. And the kids bave loudest voices drowning out a reasonable conversation. Pathetic. It all started with whoever posted that dumb shit about trolling and intel sympathizers...
Posted on Reply
#65
Parn
"Assimilator said:
That would be a major PITA since they would have to maintain a kernel build for every version of every distro. And most people who don't want to mess around with compiling their own kernel, also probably don't want to mess around getting kernel binaries from non-official distro sources. Much easier to just boot your kernel with the -nopti flag if you are running AMD/really don't want PTI enabled.

On the flipside, the majority of people and companies that actually care enough about PTI's performance impact to want it disabled, are probably already building their kernels from source - so they'll just turn it off at compile time.
Ah, so there is a boot flag to turn it off. Thank god. Now I don't have to worry about excluding the kernel update or compiling one myself on my Fedora desktop and CentOS home server.
Posted on Reply
#66
R0H1T
More info ~ https://lwn.net/Articles/738975/
Since the beginning, Linux has mapped the kernel's memory into the address space of every running process. There are solid performance reasons for doing this, and the processor's memory-management unit can ordinarily be trusted to prevent user space from accessing that memory. More recently, though, some more subtle security issues related to this mapping have come to light, leading to the rapid development of a new patch set that ends this longstanding practice for the x86 architecture.

Some address-space history
On 32-bit systems, the address-space layout for a running process dedicated the bottom 3GB (0x00000000 to 0xbfffffff) for user-space use and the top 1GB (0xc0000000 to 0xffffffff) for the kernel. Each process saw its own memory in the bottom 3GB, while the kernel-space mapping was the same for all. On an x86_64 system, the user-space virtual address space goes from zero to 0x7fffffffffff (the bottom 47 bits), while kernel-space mappings are scattered in the range above 0xffff880000000000. While user space can, in some sense, see the address space reserved for the kernel, it has no actual access to that memory.

This mapping scheme has caused problems in the past. On 32-bit systems, it limits the total size of a process's address space to 3GB, for example. The kernel-side problems are arguably worse, in that the kernel can only directly access a bit less than 1GB of physical memory; using more memory than that required the implementation of a complicated "high memory" mechanism. 32-Bit systems were never going to be great at using large amounts of memory (for a 20th-century value of "large"), but keeping the kernel mapped into user space made things worse.

Nonetheless, this mechanism persists for a simple reason: getting rid of it would make the system run considerably slower. Keeping the kernel permanently mapped eliminates the need to flush the processor's translation lookaside buffer (TLB) when switching between user and kernel space, and it allows the TLB entries for kernel space to never be flushed. Flushing the TLB is an expensive operation for a couple of reasons: having to go to the page tables to repopulate the TLB hurts, but the act of performing the flush itself is slow enough that it can be the biggest part of the cost.

Back in 2003, Ingo Molnar implemented a different mechanism, where user space and kernel space each got a full 4GB address space and the processor would switch between them on every context switch. The "4G/4G" mechanism solved problems for some users and was shipped by some distributors, but the associated performance cost ensured that it never found its way into the mainline kernel. Nobody has seriously proposed separating the two address spaces since.

Rethinking the shared address space
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. Many of those leaks date back to simpler days when kernel addresses were not sensitive information; it even turns out that your editor introduced one such leak in 2003. Nobody was worried about exposing that information at that time. 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. In all of these cases, the processor responds differently to a memory access attempt depending on whether the target address is mapped in the page tables, regardless of whether the running process can actually access that location. These differences can be used to find where the kernel has been placed — without making the kernel aware that an attack is underway.

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.

KAISER
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. The resulting patch set (still called "KAISER") is in its third revision and seems likely to find its way upstream in a relatively short period of time.

Whereas current systems have a single set of page tables for each process, KAISER implements two. One set is essentially unchanged; it includes both kernel-space and user-space addresses, but it is only used when the system is running in kernel mode. The second "shadow" page table contains a copy of all of the user-space mappings, but leaves out the kernel side. Instead, there is a minimal set of kernel-space mappings that provides the information needed to handle system calls and interrupts, but no more. Copying the page tables may sound inefficient, but the copying only happens at the top level of the page-table hierarchy, so the bulk of that data is shared between the two copies.

Whenever a process is running in user mode, the shadow page tables will be active. The bulk of the kernel's address space will thus be completely hidden from the process, defeating the known hardware-based attacks. Whenever the system needs to switch to kernel mode, in response to a system call, an exception, or an interrupt, for example, a switch to the other page tables will be made. The code that manages the return to user space must then make the shadow page tables active again.

The defense provided by KAISER is not complete, in that a small amount of kernel information must still be present to manage the switch back to kernel mode. In the patch description, Hansen wrote:
The minimal kernel page tables try to map only what is needed to enter/exit the kernel such as the entry/exit functions, interrupt descriptors (IDT) and the kernel trampoline stacks. This minimal set of data can still reveal the kernel's ASLR base address. But, this minimal kernel data is all trusted, which makes it harder to exploit than data in the kernel direct map which contains loads of user-controlled data.

While the patch does not mention it, one could imagine that, if the presence of the remaining information turns out to give away the game, it could probably be located separately from the rest of the kernel at its own randomized address.

The performance concerns that drove the use of a single set of page tables have not gone away, of course. More recent processors offer some help, though, in the form of process-context identifiers (PCIDs). These identifiers tag entries in the TLB; lookups in the TLB will only succeed if the associated PCID matches that of the thread running in the processor at the time. Use of PCIDs eliminates the need to flush the TLB at context switches; that reduces the cost of switching page tables during system calls considerably. Happily, the kernel got support for PCIDs during the 4.14 development cycle.

Even so, there will be a performance penalty to pay when KAISER is in use:
KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. 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.

Not that long ago, a security-related patch with that kind of performance penalty would not have even been considered for mainline inclusion. Times have changed, though, and most developers have realized that a hardened kernel is no longer optional. Even so, there will be options to enable or disable KAISER, perhaps even at run time, for those who are unwilling to take the performance hit.

All told, KAISER has the look of a patch set that has been put onto the fast track. It emerged nearly fully formed and has immediately seen a lot of attention from a number of core kernel developers. Linus Torvalds is clearly in support of the idea, though he naturally has pointed out a number of things that, in his opinion, could be improved. Nobody has talked publicly about time frames for merging this code, but 4.15 might not be entirely out of the question.
The most important part ~ 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. In all of these cases, the processor responds differently to a memory access attempt depending on whether the target address is mapped in the page tables, regardless of whether the running process can actually access that location. These differences can be used to find where the kernel has been placed — without making the kernel aware that an attack is underway.

So if the rumors are true then there's possibly exploits in the wild as well:banghead:
Posted on Reply
#67
Jism
Ok that's it. I'm downgrading all my servers back to Bulldozer CPU's.
Posted on Reply
#68
Vya Domus
"Assimilator said:
My speculation, however, is founded on knowledge of computer hardware
Highly debatable.
Posted on Reply
#69
Flaky
What about VIA? Nobody said they are vulnerable, but still suffer the impact from workaround-fix.
The patch should look more like "if (intel) then apply fix", rather than "if (not amd) then apply fix".
Posted on Reply
#70
EarthDog
Just report the posts instead of replying amd exacerbating the problem...

See what i mean? A self fulfilling prophecy of barbs allowed to continue after ' a hundred reports'.
Posted on Reply
#71
theoneandonlymrk
"Flaky said:
What about VIA? Nobody said they are vulnerable, but still suffer the impact from workaround-fix.
The patch should look more like "if (intel) then apply fix", rather than "if (not amd) then apply fix".
A question worth asking:) what of qualcom too and the arm derivatives are they to be penalised for intels shoddy workmanship.
Posted on Reply
#72
Jism
"Flaky said:
What about VIA? Nobody said they are vulnerable, but still suffer the impact from workaround-fix.
The patch should look more like "if (intel) then apply fix", rather than "if (not amd) then apply fix".
I dont think there are DC's working with VIA CPU's in general. VIA offers low performance / lower power CPU's with X86 yes but more suited for embedded systems. The patch goes mike tyson on every X86/X64 CPU basicly and harms performance depending on workload.
Posted on Reply
#73
Assimilator
Here's an interesting possibility as to why the PTI patch is applied to AMD as well as Intel: a partially redacted comment in the Linux kernel sources referring to a Ryzen bug that has to be worked around.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/processor.h?id=5aa90a84589282b87666f92b6c3c917c8080a9bf#n864

"jigar2speed said:
You need to keep quiet sometimes. (we know you hate AMD) The new patch is already out that excludes AMD CPUs.

<a href="https://www.reddit.com/r/hardware/comments/7nr7dy/_/ds46kfe" target="_blank" rel="nofollow">hardware/comments/7nr7dy/_/ds46kfe</a>

<a href="https://www.reddit.com/r/hardware/comments/7nqy3h/_/ds42kks" target="_blank" rel="nofollow">hardware/comments/7nqy3h/_/ds42kks</a>
1. I don't hate AMD or their CPUs. I do hate it when companies endorse their marketing teams' lies in order to sell products that they know are inferior (see: Bulldozer).
2. I prefer to source my infosec news from places other than anonymous and unverifiable Reddit comments, thanks.

"Flaky said:
What about VIA? Nobody said they are vulnerable, but still suffer the impact from workaround-fix.
The patch should look more like "if (intel) then apply fix", rather than "if (not amd) then apply fix".
I doubt the VIA x86 marketshare is large enough for it to matter whether they're affected or not. In particular, i don't imagine you'll find many of their CPUs in datacenters...
Posted on Reply
#74
Vya Domus
I find it fascinating how this thread exploded even more than the Intel one from which this whole thing started.
Posted on Reply
#75
R0H1T
I wouldn't blame any one person for it, anyway now that the booze's kicked in(?) can anyone analyze the kaiser effect OR to be more precise how AMD would be immune to this?
https://gruss.cc/files/kaiser.pdf
Posted on Reply
Add your own comment