Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

Post reply on HN
Print view View original

141–150 of 298 posts

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

#141

Post by revelation »

contrarian_ wrote: post #75
jandrese wrote: post #6

Earlier quoted context omitted.

I think the du case was an outlier. Normal workloads shouldn't be so heavily affected. I am expecting a few percent loss on most programs though. It's basically a larger penalty for making a syscall, which was already a fairly slow operation so performance minded people avoid them in tight loops. It will be bad for people who need to do lots of fast I/O I suspect.

Sounds like servers handling lots of small UDP packets would be hit pretty hard.

Applications like this where the syscall overhead (and latency) starts to be a significant factor in processing time and latency have moved to userland drivers anyway:

DPDK for 10-100 Gbps networking: https://dpdk.org/

SPDK for NVMe storage: http://www.spdk.io/

The queuing and balancing stuff the kernel does makes sense for spinning rust harddisks and residential networking, but when the underlying hardware is so fast that nothing is ever queued, really what are you doing. At 100 Gbps line speed, a 1518 byte packet takes all of ~ 120ns to transmit, or about 360 clock cycles for a 3 GHz processor.

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

#142

Post by mehrdadn »

revelation wrote: post #138
dataflow wrote: post #131

Earlier quoted context omitted.

Isn't every (edit: contended ) mutex/etc. wait operation a syscall? That's gotta hurt for any program that waits for frequent events that don't take too long to process.

Ideally a mutex is just a cmpxchg. It gets more expensive when it is contended. See the Drepper paper on futexes: http://www.akkadia.org/drepper/futex.pdf

Thanks, yeah, someone already mentioned this and I already edited in "contended" to clarify. I was actually already aware of futexes (thanks for the link though, I've never actually read the paper), but I was assuming contention -- the "every" referred to every type of operation, not every instance. See my reply to the sibling comment regarding lock contention.

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

#143

Post by emusan »

twotwotwo wrote: post #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 m…

I think the original patchset is from December 4th: https://lkml.org/lkml/2017/12/4/709 though I could be mistaken.

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

#144

Post by kentonv »

kevin_thibedeau wrote: post #94
airesQ wrote: 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?

Given what's been disclosed so far it seems an exploit using rowhammer techniques would be unlikely to work with ECC RAM. Consumer systems will be screwed unless a tolerable microcode update is released.

I don't think this issue is related to rowhammer. I think people have been speculating about rowhammer because it's a famous hardware bug, but none of the details of page table isolation seem to align with a rowhammer-based attack.

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

#146

Post by api »

BeeOnRope wrote: post #115
api wrote: 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 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 as native blobs and start shipping it as pseudocode, allowing the OS to manage native execution. This would allow the kernel and OS to do tons and tons of stuff the CPU currently does: process isolation, virtualization, much or perhaps even all address remapping, handling virtual…

Bounds checking in hardware is an awesome idea. It's still simpler than full protection modes and is more versatile. Not only does it allow efficient software JIT implementation of protection but it also allows pervasive bounds checking to eliminate buffer overflows and other common errors. It eliminates the performance incentive for a lot of unsafe code.

What I'm suggesting is not a total clean slate. It could be done easily on current processors or current instruction sets and would be more an omission than a change to core architecture.

I wonder if doing it on current chips and just ignoring all the protection and remapping logic would have a performance benefit? Look at the boost you get on some databases with transparent hugepages, which kind of do that.

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

#147

Post by dralley »

b1gtuna wrote: post #55

I thought it was clear that this patch only applies to AMD. However, reading the comments here confuses me. How's does the performance on Intel drops with this?

No, other way around. The patch which decreases Intel performance has already occurred. This patch AMD saying "we don't need this, so we're disabling it for AMD CPUs."

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

#148

Post by rayiner »

cesarb wrote: post #140
rayiner wrote: post #124

Earlier quoted context omitted.

Okay so take this bug for example. It seems to have to do with the CPU speculatively performing a load before checking that it won't generate a page fault due to user code trying to access kernel memory. Say you get rid of process isolation, etc. How do you protect kernel code from user code? You can't do any sort of static analysis I'm aware of that'll still allow you to run C code (which let's you manufacture point…

> And if you insert dynamic checks instead, you're talking about turning each memory access into many (memory accesses that in a modern CPU are hidden by the TLB). You only have to check that the memory address is not negative (kernel pointers are negative on x86-64). No extra memory access needed. > You can't do any sort of static analysis I'm aware of that'll still allow you to run C code (which let's you manufactu…

Good point about the ease of checking kernel pointers. That doesn't address process isolation generally, however, unless you're willing to segment virtual memory in the same way.

As to NACL, it relies on various CPU protection mechanisms, and also makes some major trade-offs: https://static.googleusercontent.com/media/research.google.c.... On x86, NACL uses the segmentation mechanism. On x86-64, which has no segmentation registers, it masks addresses and requires all memory references to be in a 4GB space. To handle various edge cases, and to speed up stack references, it relies on huge guard areas on either side of the module heap and stack, thus relying on the virtual memory system. Finally, likely to mitigate the overhead of masking, it does not address reads at all, and relies on the virtual memory system to protect secret browser information from the sandboxed process. Even with these limitations, on about half the SPEC benchmarks the overhead is 15-45%.

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

#149

Post by sitkack »

revelation wrote: post #72
IgorPartola wrote: post #67

Earlier quoted context omitted.

Has there ever been a precedent for this? When there were major bugs in Intel CPU's (or drives, or RAM, or motherboards) did the likes of Amazon and Google invest in diversification? And has it affected stock prices meaningfully? My guess is that they'll see this as just another one off issue that can be fixed with software, then move on. For a large enterprise, monoculture that works is actually better than diversif…

I checked the stock of Intel during the FDIV bug (1994/1995) where they had to go as far as recalling the affected processors at a cost of $500M in January 1995 and there was basically zero effect. By the end of 1995 the stock had actually pretty much doubled in value..

I personally think FDIV made Intel money, it told the world how important Intel was. It wasn't just the calculator sitting on some trader's desk. It ran the stock market and the stock market responded.

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

#150

Post by amckenna »

calt wrote: post #145
caio1982 wrote: post #139

Did he know it would blow up in a few weeks? https://www.fool.com/investing/2017/12/19/intels-ceo-just-so...

What's the connection?

Here is some more context - http://pythonsweetness.tumblr.com/post/169166980422/the-myst...

The connection between the linked article in this comment and the linked page for this post is that there is a potentially huge bug that will be made public soon and it just affects Intel processors, not AMD - hence the large sale of stock by the Intel CEO.

Post reply on HN