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

131–140 of 298 posts

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

#131

Post by dataflow »

jandrese wrote: post #6
anonacct37 wrote: post #2

This feels like a big FU to Intel. I've heard this patch can slow down programs like du by 50%. Does that mean AMD is going to find itself running twice as fast as competitors?

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.

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.

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

#132

Post by twotwotwo »

my123 wrote: post #61
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…

The author of https://cyber.wtf/2017/07/28/negative-result-reading-kernel-... is listed in the Acknowledgements part as the first name in the Kaiser whitepaper.

Ah, yes, that does look like an earlier public clue. Thanks.

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

#133

Post by brazzledazzle »

jandrese wrote: post #6
anonacct37 wrote: post #2

This feels like a big FU to Intel. I've heard this patch can slow down programs like du by 50%. Does that mean AMD is going to find itself running twice as fast as competitors?

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.

This may end up doing some significant hurt to some build and testing pipelines.

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

#134

Post by mortehu »

dataflow wrote: post #131
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.

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.

They are only system calls when you need to wait or wake up processes.

https://en.m.wikipedia.org/wiki/Futex

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

#135

Post by kevin_thibedeau »

Shank wrote: post #113
kevin_thibedeau wrote: post #94

Earlier quoted context omitted.

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 was under the impression that rowhammer could work because ECC ram can't correct for a high number of errors. Specifically "However, even such modules cannot correct multi-bit disturbance errors" from http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf .

With such a crude mechanism the odds are pretty slim that you can create all the right multi-bit flips in one go without hitting an intermediate state that triggers an ECC fault. Research theorizing and actual practice aren't always the same.

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

#136

Post by Sir_Substance »

IgorPartola wrote: post #129
Sir_Substance wrote: post #122

Earlier quoted context omitted.

If Intel weren't under pressure to keep a negative-ring network enabled snoopstack open by an external entity, they would by now definitely have released an update that allowed people to disable the networking aspect of IME. Major system vendors are now offering to apply bootleg removal situations at the factory on customer request[1]. That request is not free. People are willing to /pay extra/ for no-IME laptops. Ei…

OK, but that's (a) 100% speculation and (b) fails Hanlon's razor. I don't like the fact that you can't disable ME, that it's not open source, and that it's vulnerable any more than anyone else. But this does seem like hyperbole much more than fact.

>OK, but that's (a) 100% speculation

95% speculation. The last 5% comes from exercising basic pattern recognition.

I remind you that we're probably talking about interference from the organization that arranged this:

https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...

The existence of that program was pure speculation, until it turned out to be totally real.

>(b) fails Hanlon's razor.

This is completely irrelevant to any argument made between two informed participants. It's worse than speculation, it's a plea to glib colloquialisms. Any chance you've got evidence or even reasoned speculation supporting the theory that the worlds most successful CPU manufacturer has an incompetent marketing department?

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

#137

Post by mehrdadn »

mortehu wrote: post #134
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.

They are only system calls when you need to wait or wake up processes. https://en.m.wikipedia.org/wiki/Futex

I was assuming contention but I guess I wasn't clear, sorry. I updated the post. But saying this "only" occurs when there is contention is very misleading since it makes it seem like the scenario of lock contention is a negligible concern. It's not.

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

#138

Post by revelation »

dataflow wrote: post #131
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.

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

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

#140

Post by cesarb »

rayiner wrote: post #124
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…

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 manufacture pointers from arbitrary integers).

NaCl managed to do it (https://developer.chrome.com/native-client/reference/sandbox...).

Post reply on HN