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

61–70 of 298 posts

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

#61

Post by my123 »

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.

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

#62

Post by amluto »

rurban wrote: post #43
amluto wrote: post #20

Earlier quoted context omitted.

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....

I think you're still misunderstanding. The CPU picks TTBR0 or TTBR1 based on the top significant bit of the VA, irrespective of whether the access was initiated by user or kernel code. This is in contrast to s390, which has separate page tables for user mode and kernel mode. I personally much prefer s390's model.

And yes, I've read quite a few papers, and I wrote a good fraction of the patches.

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

#63

Post by wolf550e »

tankenmate wrote: post #41
pm215 wrote: post #21

Earlier quoted context omitted.

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?

Linux kernel has a compatibility guarantee to the user space visible API, so static binaries will continue to run. If the static binary is so old it does not know about vdso and uses regular syscall to query time, it will be slowed down.

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

#64

Post by IgorPartola »

ComputerGuru wrote: post #44
SteveNuts wrote: post #31

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.

ME is actually a gasp useful feature. The problem is with Intel's implementation of it: it's not open source, it can't be disabled, and it's buggy. Fix all three of those, and Intel's stock will go up.

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

#65

Post by keltor »

amluto wrote: post #32
floatboth wrote: post #18

Earlier quoted context omitted.

Probably the paid hardware RAID unlock key.

Has Intel ever had hardware RAID? They have firmware RAID, but that's quite different.

They actually DID have hardware RAID controllers, but not like you're talking about.

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

#66

Post by kuschku »

amluto wrote: post #56
kuschku wrote: post #46

Earlier quoted context omitted.

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.

PTI has been merged.

But it’s not been released yet, right?

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

#67

Post by IgorPartola »

dboreham wrote: post #53
IgorPartola wrote: post #27

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.

I think it will because it shows the downside of a monoculture. Hence big purchasers of CPUs will want to diversify. Also good for ARM vendors I suppose. Disclosure : bought AMD this morning before headlines saying "Buy AMD, short INTC" appeared.

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 diversification.

When you think about your own workstation, it's not a big deal to build an Intel or AMD system. But when you buy 100k motherboards and spend the time adjusting your tooling to those, from packaging to power, to cooling, to support, to OS code, etc. and then you on a whim decide to get another 100k motherboards of a different architecture, you spend a non-trivial amount of time and money to support those as well. Again, if AMD provides better hardware, it's absolutely worth it. But I personally wouldn't do it based on this bug.

I don't own shares of either AMD or Intel.

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

#68

Post by rurban »

amluto wrote: post #62
rurban wrote: post #43

Earlier quoted context omitted.

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....

I think you're still misunderstanding. The CPU picks TTBR0 or TTBR1 based on the top significant bit of the VA, irrespective of whether the access was initiated by user or kernel code. This is in contrast to s390, which has separate page tables for user mode and kernel mode. I personally much prefer s390's model. And yes, I've read quite a few papers, and I wrote a good fraction of the patches.

Oh, thanks. My fault then. I haven't read the arm patches, only the summary.

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

#69

Post by zzzcpan »

IgorPartola wrote: post #60
userbinator wrote: post #57

Earlier quoted context omitted.

No, it's only because of "JS is now a part of the web" advocates that we've gotten into this horrible situation. but then they go back to leading a much more difficult online life than the rest of the world. I completely disagree, because I don't have to routinely subject myself to the barrage of useless distracting noise (adverts and whatever else) caused by JS. https://news.ycombinator.com/item?id=10871967 (The res…

I care about security and I do have a problem with it. http://www.logicalfallacies.info/presumption/no-true-scotsma... Yes I advocate for JS to be a part of the web. There are good reasons for it. But regardless, it has nothing to with advocates. We are in this situation because browser vendors included JS and developers and users found it useful. Again, you are free to deny the idea that this is irreversible, but I…

> and spend a whole lot of their lives fiddling with drop down menus to enable/disable JS

Even without special extensions and keyboard shortcuts you spend very little time on fiddling with menus. It seems like a lot only at the beginning and quickly gets to near no fiddling at all. But it also saves time on various things, like when your adblocker doesn't catch something and you have to close those clickunder born popups or see a page full of ads where it's hard to even find the content, things also load faster and so on.

My only problem without javascript is cloudflare. They truly are sabotaging it, giving impossible to solve captchas for example.

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

#70

Post by daenney »

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…

It wasn't publicly acknowledged but people figured it out already. Take a look at https://news.ycombinator.com/item?id=16046636 (both the article and the comments) for example. This wasn't going to stay secret much longer.
Post reply on HN