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

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

#51

Post by gecko » Tue, Jan 02, 2018, 6:01 PM UTC

kps wrote: post #47

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…

> It's such an obvious thing I'm really surprised nobody's done it. IBM AS/400 for about 30 years now.

Tao/Intent/Elate (which I think is defunct nowadays) would also qualify, and I'd argue .NET on Windows with the GAC would, too (although there'll be a legitimate argument about whether that's "simple and closely models the processor").

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

#52

Post by brians » Tue, Jan 02, 2018, 6:04 PM UTC

rrdharan wrote: post #16

mindcrash wrote: post #12

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?

IIRC, this fall’s i9 chips and the motherboards supporting them have software-unlockable features. You can literally buy more PCI lanes.

Which is another way of saying you had those lanes, and Intel wanted more money before letting you use what you’d already bought.

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

#53

Post by dboreham » Tue, Jan 02, 2018, 6:06 PM UTC

IgorPartola wrote: post #27

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.

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.

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

#54

Post by dboreham » Tue, Jan 02, 2018, 6:07 PM UTC

cjbprime wrote: post #40

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

Are you sure that all Intel CPUs are affected? Might just be older ones.

The kernel code changes target all Intel.

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

#55

Post by b1gtuna » Tue, Jan 02, 2018, 6:07 PM UTC

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?

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

#56

Post by amluto » Tue, Jan 02, 2018, 6:09 PM UTC

kuschku wrote: post #46

spiznnx wrote: post #45

Earlier quoted context omitted.

Nothing will happen since this patch will speed up AMD hardware, but leave Intel the same as before.

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.

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

#57

Post by userbinator » Tue, Jan 02, 2018, 6:09 PM UTC

IgorPartola wrote: post #37

userbinator wrote: post #35

Earlier quoted context omitted.

All the more reason to keep JS off by default... ...but the blog post above shows that you need to execute instructions that (try to) access kernel addresses, and have a handler in place to catch the inevitable exception. That doesn't seem like code a JS JIT could generate. You might be thinking of that JS RowHammer demonstration, but that was using regular memory accesses and not with the specific kernel addresses t…

Sorry that train has left the station. JS is now a part of the web. The advice to keep JS off by default is a lot like saying "turn off your Wi-Fi by default" and "don't use a computer." People that do it occasionally experience an exaggerated sense of smugness when a particularly nasty bug is discovered, but then they go back to leading a much more difficult online life than the rest of the world.

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 rest of the comments on that item are worth reading too.)

Also, "JS off" is very much in agreement with "don't run untrusted code", something which everyone who cares about security in any way would have no problem with.

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

#58

Post by caio1982 » Tue, Jan 02, 2018, 6:10 PM UTC

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?

Because of the rest of the patch set. This one simply says "AMD CPUs should not be penalized [by such patch set changes]".

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

#59

Post by cr0sh » Tue, Jan 02, 2018, 6:12 PM UTC

kps wrote: post #47

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…

> It's such an obvious thing I'm really surprised nobody's done it. IBM AS/400 for about 30 years now.

It also made me think of PICK (and PICK cpu hardware implementations); though I never learned enough about the internals of PICK when I last used it 20+ years ago (so I could be wildly off-base).

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

#60

Post by IgorPartola » Tue, Jan 02, 2018, 6:13 PM UTC

userbinator wrote: post #57

IgorPartola wrote: post #37

Earlier quoted context omitted.

Sorry that train has left the station. JS is now a part of the web. The advice to keep JS off by default is a lot like saying "turn off your Wi-Fi by default" and "don't use a computer." People that do it occasionally experience an exaggerated sense of smugness when a particularly nasty bug is discovered, but then they go back to leading a much more difficult online life than the rest of the world.

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 am with the 99.99% of users of the web who have JS enabled.

Edit: QoL is subjective of course, but let me ask you this: when was the last time you really had JS enabled by default and how did you measure the trade off? My suspicion is that most people who put on their tin foil hat^W^W^W^W^W^Wturn off JS by default don't actually turn it back on frequently, and spend a whole lot of their lives fiddling with drop down menus to enable/disable JS on specific sites.