Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

41–50 of 298 posts

Re: Linux page table isolation is not needed on AMD processors

#41
post #21

Earlier quoted context omitted.

Some portable / embedded databases come to mind. Also "normal" databases doing replication initiation, and replication re-sync. And lastly backup, restore, tar, etc with small files. For files under a handful of pages long mmap() isn't a big gain. Another syscall I think that might cause issues is gettimeofday(), that particular call has been optimised to the nth degree, and lots of user programs spam the crap out of…

Linux gettimeofday these days is implemented in the 'vdso', which is code provided by the kernel that runs solely in userspace. So it's not a syscall in the 'privilege level switch by executing insn that takes an exception' sense and shouldn't be affected by the syscall-entry/exit path becoming more expensive.

Does this also apply to vsyscall's being emulated? Will this mean that older static binaries will no longer run? or just suffer a penalty as well?

Re: Linux page table isolation is not needed on AMD processors

#43
post #20
post #11

Earlier quoted context omitted.

What are you talking about? Every other single CPU vendor with an MMD, arm, s390, Sparc, ... either has a separate page translation table register for kernel and user space, or like AMD memory page capabilities, just Intel not. It's very clear who is at fault here.

Not ARM. You're confusing kernel mode with kernel addresses.

Nope, read the paper, read the patches. Only Intel is affected. Arm has two such registers, TTB0 and TTB1. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....

Re: Linux page table isolation is not needed on AMD processors

#44

Earlier quoted context omitted.

Short INTC maybe but I am not sure this means that AMD will increase in value over the long run as a result of this one incident.

What about this combined with the Intel ME stuff? I could see large cloud providers starting to at least think about switching to AMD

AMD has their own ME equivalent in their recent CPUs.

Re: Linux page table isolation is not needed on AMD processors

#45
post #38

Given Intel's dominance of the server market does this mean that datacenter computational capacity will see an overnight ~5% drop? Is there enough spare capacity to cope with this? Will spot-instance prices go up? Will I need more instances of a given type to run the same workload?

Nothing will happen since this patch will speed up AMD hardware, but leave Intel the same as before.

Re: Linux page table isolation is not needed on AMD processors

#46
post #45
post #38

Given Intel's dominance of the server market does this mean that datacenter computational capacity will see an overnight ~5% drop? Is there enough spare capacity to cope with this? Will spot-instance prices go up? Will I need more instances of a given type to run the same workload?

Nothing will happen since this patch will speed up AMD hardware, but leave Intel the same as before.

This patch is part of a patchset that isn’t merged yet. The patchset adds 29% (with PCID) or > 50% (without PCID) overhead to syscalls on Intel processors.

Overall, this has between 0.28% (best case application with barely any syscalls) and > 50% (du, which does lots of syscalls) impact on performance on Intel processors.

Re: Linux page table isolation is not needed on AMD processors

#47
post #36

At the meta level this is just a special case of "complexity is evil" in security. CPUs have been getting more and more complex, and the relationship between complexity and bugs (of all types) is exponential. Each new CPU feature exponentially increases the likelihood of errata. A major underlying cause is that we're doing things in hardware that ought to be done in software. We really need to stop shipping software…

> It's such an obvious thing I'm really surprised nobody's done it.

IBM AS/400 for about 30 years now.

Re: Linux page table isolation is not needed on AMD processors

#48
post #36

At the meta level this is just a special case of "complexity is evil" in security. CPUs have been getting more and more complex, and the relationship between complexity and bugs (of all types) is exponential. Each new CPU feature exponentially increases the likelihood of errata. A major underlying cause is that we're doing things in hardware that ought to be done in software. We really need to stop shipping software…

A lot of these ideas were in the back of our heads in designing WebAssembly, but to keep expectations low, we don't make too much noise about them. However I personally believe that we are on the right track with WASM and am very excited about the future!

Re: Linux page table isolation is not needed on AMD processors

#49
Was the connection with speculative execution already being discussed openly? I know about https://cyber.wtf/2017/07/28/negative-result-reading-kernel-..., but not about anything between that and 28 Dec suggesting someone made it work and that's the reason for KPTI.

If it wasn't in the open, seems...not ideal embargo-wise for AMD to leak it there. Though no one's in that thread complaining about the disclosure, so maybe they either think that part is already known to anyone looking closely, or just don't think it's a very big piece of the exploit puzzle (like, finding the way to get info out a side channel was the hard part).

Re: Linux page table isolation is not needed on AMD processors

#50

Earlier quoted context omitted.

What about this combined with the Intel ME stuff? I could see large cloud providers starting to at least think about switching to AMD

AMD has their own ME equivalent in their recent CPUs.

Yes, but on recent motherboards with recent AMD CPUs, a bios option to turn the PSP off has appeared, and support says that’s exactly what it does.
Post reply on HN