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

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

#101

Post by pm215 » Tue, Jan 02, 2018, 8:59 PM UTC

gecko wrote: post #51

kps wrote: post #47

Earlier quoted context omitted.

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

Tao is long defunct, yes (went under a decade ago). It turns out that people don't really want a runtime-portable OS/apps (IIRC the biggest takeup it got was as a Java runtime for mobile, because the competition at that time was all interpreted). There was no security model in VP, though -- single flat address space and bytecode could turn any integer into a pointer and dereference it (loads just got translated into host cpu load instructions), so there was no isolation between processes or between processes and the os.

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

#102

Post by djsumdog » Tue, Jan 02, 2018, 9:00 PM UTC

nine_k wrote: post #87

zer00eyz wrote: post #82

I have to wonder: Can intel release a drop in CPU that will avoid or mitigate this issue? The infrastructure investment in intel cores is huge, if a drop in replacement lets me minimize downtime, re-gain performance and is "cost effective" compared to a cost prohibitive replacement does this result in intel having a sales INCREASE where it replaces bad silicon? I don't know enough about this issue to speak to the iss…

I wonder if this can be fixed at firmware level. (I frankly have no idea how deeply configurable Intel cores are.)

For years, Intel and AMD processors have supported patching using microcode updates. Until we know the embargo is lifted and we know the full extent of this vulnerability, we won't know if that would be possible.

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

#103

Post by JackFaker » Tue, Jan 02, 2018, 9: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.

This is probably completely unrelated but apparently Intel's CEO sold a large amount of stock late last year. https://www.fool.com/investing/2017/12/19/intels-ceo-just-so...

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

#104

Post by nine_k » Tue, Jan 02, 2018, 9:06 PM UTC

djsumdog wrote: post #102

nine_k wrote: post #87

Earlier quoted context omitted.

I wonder if this can be fixed at firmware level. (I frankly have no idea how deeply configurable Intel cores are.)

For years, Intel and AMD processors have supported patching using microcode updates. Until we know the embargo is lifted and we know the full extent of this vulnerability, we won't know if that would be possible.

The fact that the firmware interface is strictly non-public also does not help predicting things.

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

#105

Post by sedachv » Tue, Jan 02, 2018, 9:07 PM UTC

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…

> We really need to stop shipping software as native blobs and start shipping it as pseudocode, allowing the OS to manage native execution.

What we really need to do is to start shipping all software as source code. This is exactly what JavaScript does, and why it is the most successful method of software distribution ever. WebAssembly is a huge step backward.

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

#106

Post by ambrop7 » Tue, Jan 02, 2018, 9:13 PM UTC

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.

I think syscalls are not as slow as many people imagine they are, especially with modern CPUs and kernels (there are special instruction for syscalls that are faster than the old "interrupt" approach). See here: http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemil... ("Off-topic: A system call"). But they will be slow with this mitigation.

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

#107

Post by tedunangst » Tue, Jan 02, 2018, 9:16 PM UTC

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…

A leaking embargo? I'm shocked!

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

#108

Post by Sir_Substance » Tue, Jan 02, 2018, 9:16 PM UTC

IgorPartola wrote: post #79

zanny wrote: post #74

Earlier quoted context omitted.

Do you really think enough people care about the ME / control of hardware in general / hardware that spies on you or is out of your control to influence the stock price of a company the size of Intel?

No. That's exactly what I'm saying. Most people don't care. Enterprise users do care because ME is useful for them. It's a feature, not a nefarious backdoor that the NSA made Intel include under the cover of darkness. They'll see this as a small problem that should be fixed and will ask Intel to do so. Intel will fix it, most everyone will move on. I don't think ME will take down Intel stock, and neither will this pa…

>It's a feature, not a nefarious backdoor that the NSA made Intel include under the cover of darkness.

Let's be clear: It's both.

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

#109

Post by jhasse » Tue, Jan 02, 2018, 9:19 PM UTC

unethical_ban wrote: post #100

brians wrote: post #52

Earlier quoted context omitted.

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.

AMD's triple core processors were quads with disabled cores. Often times processors within a line are processors with manually set lower clock multipliers or disabled cache. Sounds like Intel has just made it unlockable instead of permanent. It just brings to the fore what was already being done, and makes us question again the ethics of pricing models.

You can't unlock all triple cores to quad cores though. It's called binning and all chip manufacturs do it.

The chipset unlock thing is different as there's no technical reason to lock it in the first place.

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

#110

Post by rdtsc » Tue, Jan 02, 2018, 9:22 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 there is a critical opportunity for AMD here to take this to the public and the media. Basically kick Intel while it is down. Intel will probably recover fine, but AMD shouldn't miss its chance either. Investors and such might pay attention to that and start selling INTC and buying AMD.