Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

11–20 of 298 posts

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

#11

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 text as written only seeks to defend AMD's product. Whether the sub text goes further is open to non objective speculation. Having said that I'm sure AMD are feeling pretty happy with their statement. Schadenfreude may be too long a bow...

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.

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

#14
post #9
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.

It sounds like databases on very fast storage will be updated. Tons of syscalls made for disk io and network io.

Databases are already written to minimise syscalls, like any other heavily performance-tuned system.

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

#15
post #5

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 50% figure is from a benchmark that didn't run on an Intel CPU!

    - /* Assume for now that ALL x86 CPUs are insecure */
Before this patch the mitigation was active for all vendors.

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

#16

So first they bring a DLC concept ("unlock features by spending money") to their enthousiast platform, and now this? Having a hunch Threadripper will sell extremely well amongst PC enthousiasts this year...

I'm curious what you are referring to re: the DLC concept? Did you mean this thing?

https://en.wikipedia.org/wiki/Intel_Upgrade_Service

Seems like that was discontinued a long time ago (2011) so was wondering if there was something more recent that happened?

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

#17

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.

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

#18

So first they bring a DLC concept ("unlock features by spending money") to their enthousiast platform, and now this? Having a hunch Threadripper will sell extremely well amongst PC enthousiasts this year...

I'm curious what you are referring to re: the DLC concept? Did you mean this thing? https://en.wikipedia.org/wiki/Intel_Upgrade_Service Seems like that was discontinued a long time ago (2011) so was wondering if there was something more recent that happened?

Probably the paid hardware RAID unlock key.

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

#19
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…

vDSO-based timing is unaffected.

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

#20
post #11

Earlier quoted context omitted.

The text as written only seeks to defend AMD's product. Whether the sub text goes further is open to non objective speculation. Having said that I'm sure AMD are feeling pretty happy with their statement. Schadenfreude may be too long a bow...

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.
Post reply on HN