Linux page table isolation is not needed on AMD processors • Hacker News Board

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

#21

Post by pm215 » Tue, Jan 02, 2018, 4:48 PM UTC

tankenmate wrote: post #10

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.

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.

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

#22

Post by tscs37 » Tue, Jan 02, 2018, 4:49 PM UTC

blattimwind wrote: post #4

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?

"The overhead was measured to be 0.28% according to KAISER's original authors,[2] but roughly 5% for most workloads by a Linux developer.[1]" [1] = https://lwn.net/Articles/738975/ Though the patches evolved since then. So I guess we'll see.

I believe the 0.28% are only for CPUs that support PCID. Earlier CPUs (which is a lot still) will get a much harder hit since you'll have to flush the entire TLB.

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

#23

Post by my123 » Tue, Jan 02, 2018, 4:49 PM UTC

bitwind wrote: post #17

userbinator wrote: post #13

All that I've read about this so far seems to indicate that it's only a way to bypass KASLR... which is itself not really a problem, but there must be something more to it. Given that it doesn't affect AMD, perhaps it's related to Intel ME?

The growing consensus is that someone managed to make this work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-... Reading kernel memory from user mode = reading cached disk blocks, cached credentials and anything else, by simply running javascript on a web browser. KASLR bypass is just a small bonus.

It is that.

The author of that blogpost is mentioned in Acknowledgments on the Kaiser whitepaper. :)

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

#24

Post by rdtsc » Tue, Jan 02, 2018, 4:54 PM UTC

bitwind wrote: post #8

All Intel CPU's are affected, mitigation syscall overhead increased by 50%, and none of AMD CPU's affected? I would say this could be an indicator to short INTC and long AMD...

> I would say this could be an indicator to short INTC and long AMD...

I would say that too if I'd be waiting for everyone to sell so then I could buy INTC :-)

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

#25

Post by my123 » Tue, Jan 02, 2018, 4:57 PM UTC

tscs37 wrote: post #22

blattimwind wrote: post #4

Earlier quoted context omitted.

"The overhead was measured to be 0.28% according to KAISER's original authors,[2] but roughly 5% for most workloads by a Linux developer.[1]" [1] = https://lwn.net/Articles/738975/ Though the patches evolved since then. So I guess we'll see.

I believe the 0.28% are only for CPUs that support PCID. Earlier CPUs (which is a lot still) will get a much harder hit since you'll have to flush the entire TLB.

Even with PCID, the hit is 29% in a tight syscall loop, but is a complete disaster above 50% with PCID off...

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

#26

Post by userbinator » Tue, Jan 02, 2018, 4:58 PM UTC

my123 wrote: post #23

bitwind wrote: post #17

Earlier quoted context omitted.

The growing consensus is that someone managed to make this work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-... Reading kernel memory from user mode = reading cached disk blocks, cached credentials and anything else, by simply running javascript on a web browser. KASLR bypass is just a small bonus.

It is that. The author of that blogpost is mentioned in Acknowledgments on the Kaiser whitepaper. :)

Interesting. I can see it being a concern in shared environments (hence all the cloud providers are quite scared), but unless there's another part about being able to modify kernel memory, IMHO it's not such a big deal for the typical single-user personal computer.

I wonder if there are other (non-x86) CPUs that do similar speculative execution affected... the general ideas behind it don't seem to be specific to x86.

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

#27

Post by IgorPartola » Tue, Jan 02, 2018, 5:04 PM UTC

bitwind wrote: post #8

All Intel CPU's are affected, mitigation syscall overhead increased by 50%, and none of AMD CPU's affected? I would say this could be an indicator to short INTC and long AMD...

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.

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

#28

Post by rdudek » Tue, Jan 02, 2018, 5:07 PM UTC

How does all this affect everyday regular users?

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

#29

Post by IgorPartola » Tue, Jan 02, 2018, 5:09 PM UTC

userbinator wrote: post #26

my123 wrote: post #23

Earlier quoted context omitted.

It is that. The author of that blogpost is mentioned in Acknowledgments on the Kaiser whitepaper. :)

Interesting. I can see it being a concern in shared environments (hence all the cloud providers are quite scared), but unless there's another part about being able to modify kernel memory, IMHO it's not such a big deal for the typical single-user personal computer. I wonder if there are other (non-x86) CPUs that do similar speculative execution affected... the general ideas behind it don't seem to be specific to x86.

How so? Letting any old web page read your kernel’s memory seems like kind of a big deal to me. On the other hand I guess remote debugging will be a lot easier in 2018 :)

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

#30

Post by Unklejoe » Tue, Jan 02, 2018, 5:15 PM UTC

userbinator wrote: post #26

my123 wrote: post #23

Earlier quoted context omitted.

It is that. The author of that blogpost is mentioned in Acknowledgments on the Kaiser whitepaper. :)

Interesting. I can see it being a concern in shared environments (hence all the cloud providers are quite scared), but unless there's another part about being able to modify kernel memory, IMHO it's not such a big deal for the typical single-user personal computer. I wonder if there are other (non-x86) CPUs that do similar speculative execution affected... the general ideas behind it don't seem to be specific to x86.

> IMHO it's not such a big deal for the typical single-user personal computer

IDK. If this means that some JavaScript from a website can read my kernel's memory, then it seems like a big deal.