Yup, I think so. In that case (PCID hardware on a PCID-enabled kernel), the performance effect should be more limited to the syscall itself. That said, why is the hit still so big with PCID? Surely just the CR3-swap by itself shouldn't be so slow?
MOV-to-CR3 is pretty slow, yes. In the ballpark of a hundred clock cycles, and you have to do 2 of them. The cost of a system call was about 1000 cycles, maybe less on newer processors---both OSes and processors optimize the hell out of SYSCALL/SYSRET.
This is going to have dramatic effect on the cloud computing market. It might make sense to make sure any VMs you run are on AMD processors or it can really hurt your performance and basically cost you more to do the same workload. It also seems, from early benchmarks, this can slaughter performance with databases.
Why are people insisting this affects cloud computing market? I am not sure if this bug is absolutely limited to cloud instances.
The bug affects transistions into kernel mode. Virtual machines have one extra transistion. A read() call in the guest calls the guest OS which calls the host OS.
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…
I think the original patchset is from December 4th: https://lkml.org/lkml/2017/12/4/709 though I could be mistaken.
That's "a major overhaul of the KAISER patches" as the commit message says. It doesn't mention the connection to speculative execution, though; that was the bit I was interested in.
Why are people insisting this affects cloud computing market? I am not sure if this bug is absolutely limited to cloud instances.
The bug affects transistions into kernel mode. Virtual machines have one extra transistion. A read() call in the guest calls the guest OS which calls the host OS.
You are referring to the slow down and hence the extra slow down for calling an extra syscall?
If so, then isn't it technically correct that the bug will affect regardless of virtualization or not, but heavier penalty for VMs?
This is going to have dramatic effect on the cloud computing market. It might make sense to make sure any VMs you run are on AMD processors or it can really hurt your performance and basically cost you more to do the same workload. It also seems, from early benchmarks, this can slaughter performance with databases.
Don't worry. I don't think that there will be two separate kernels for Intel and AMD. I think performance drop will be on both CPUs no matter has it the bug or not.
Is it? Again, that a big claim to make in five words and drop the mic. Can you cite anything to back it up?
It creates a huge attack vector on most computers that the user has almost no control over. Even if Intel are completely uninvolved, some intelligence agency will try to exploit it.
The claim at hand, however, was that the NSA made Intel include it.
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.
JS is only part of the browser . Accusing people not running browsers that expose them to a nasty bug of feeling an exaggerated sense of "smugness"? This seems disrepectful of users. Doesnt that violate HN guidelines?
What I meant by this is that JS relies on a browser with an interpreter. If we use one without an interpreter then JS is nothing but text. I guess one could claim that this text is "part of the web". The point is that it is the users choice whether to run the it through an interpreter. Sometimes they might want to do that (maybe offline), other times they might not. Most times I do not need to run JS to get what I am after (e.g., text, documents, videos, etc.). There is just no need to run all these third party scripts to read some text or download a file for offline viewing. I may read the JS though. In that sense, yes, it is "part of the web". It just isnt the content part that users care about.
It creates a huge attack vector on most computers that the user has almost no control over. Even if Intel are completely uninvolved, some intelligence agency will try to exploit it.
The claim at hand, however, was that the NSA made Intel include it.
No, the claim being made is that ME is being added as a feature, with a hyperbolic version of the other argument tacked on. Whether they were forced to include it doesn't matter, the way they included it benefits the intelligence agencies.
Google has stated that they would move to the power9 if the performance claimes live up to the hype. That has yet to be seen.
POWER has been better performing than intel since basically 1990, though intel's tick/tock cadence and trading blows in fab tech have kept things interesting. That shouldn't be surprising since POWER is ultra focused on the high end and intel is fending off attacks from the low end and never had good long term thinking on the high end. The reason every server isn't POWER is: ecosystem. For any random company, switchi…
Right. I think HPC will be the first to take on POWER9 since it has some huge advantages with CAPI and PCIe v4. Outside of that, it will take some run time to convince the larger cloud providers it's useful.
I believe POWER9 has the ability to be either big or little endian as well, so that helps for compatibility issues, and it's just a matter of whether your application can compile.
Applications like this where the syscall overhead (and latency) starts to be a significant factor in processing time and latency have moved to userland drivers anyway: DPDK for 10-100 Gbps networking: https://dpdk.org/ SPDK for NVMe storage: http://www.spdk.io/ The queuing and balancing stuff the kernel does makes sense for spinning rust harddisks and residential networking, but when the underlying hardware is so fas…
> Applications like this where the syscall overhead (and latency) starts to be a significant factor in processing time and latency have moved to userland drivers anyway: I would personally think that is worse, though please correct me if I'm wrong. The userland driver will run with an isolated PT like any other userland process won't it? If so, it will suffer the same slowdown that every other process now has every-t…
It's counter intuitive at first, but the key to understand how this works is that while you can use an MMU to assign chunks of physical memory to a process, you can of course also just use the MMU to assign the memory mapped IO registers of say a PCI express peripheral to a process.
That is in a nutshell what a "userland driver" is. It's not too far removed from poking the parallel port at 0x378 on your DOS computer :)