7 ms·
The Intel flaw exposed something interesting: We could get a >50% performance boost by ignoring security. Think about that. 1.5x - 2x boost, on a single core.
by shawn 9y ago
The Intel flaw exposed something interesting:
We could get a >50% performance boost by ignoring security.
Think about that. 1.5x - 2x boost, on a single core. That's like doubling a CPU's clock speed, except more powerful since it involves caching memory (which is usually the bottleneck, not raw horsepower).
What would the TempleOS of CPUs look like, I wonder?
We ought to have the option of running workloads on such CPUs. Yes, they're completely compromised, but if you're running a game server you really don't have to care very much. Most data is ephemeral, and the data that isn't, isn't usually an advantage to know.
Being able to run twice the workload as your competitors on a single core is a big advantage. You saw what happened when performance suddenly dropped thanks to the patch.
- bitwize 9y agoSome Amiga people still believe that "virtual memory" is a passing fad, and when the Amiga comes again in glory we'll all realize how futile and self-defeating it was to prevent people from accessing the raw hardware and OS.
- akvadrako 9y agoAlso, unikernels move in this direction. If you just run one program per VM, virtual memory doesn't gain you much security.
- snaky 9y agoIncludeOS especially. > One service pr. VM means no need for virtual address spaces, and no overhead due to address translation. Everything happens in a single, ring 0 address space.
- cm2187 9y agoPlus this is not a security issue on a single tenant server running only the game server code.
- AdamJacobMuller 9y agoThere are some plausible ways it could still be exploited, but, I would say those deserve higher in the stack mitigations. As a contrived example, a game server that accepts maps over the network that can contain a scripting language like Lua/javascript could theoretically cause data leaks. By higher in the stack mitigations, I mean things like neutering the javascript timer accuracy in chrome fix to Meltdown/Spectre.
- userbinator 9y agoThis brings to mind articles and discussions I read in the early 90s about differences in performance between running in real (or "unreal") mode and protected mode --- yes, the extra permission checks, paging, segmentation, etc. definitely add some overhead: https://groups.google.com/d/topic/comp.lang.asm.x86/YbQJ_m0dDUg https://groups.google.com/d/topic/comp.lang.asm.x86/YbQJ_m0d... Thus they decided to do permissions checking in parallel with other operations, leading to Spectre. It's interesting to note that the original intent of protected mode was not as a real secure "security feature" immune from all attacks, but more to provide some isolation to guard against accidents and expand the available address space. The entire Win9x series of OSs embody this principle. What would the TempleOS of CPUs look like, I wonder? x86 running in unreal mode might be close. I wonder if anyone has done any benchmarking of recent x86 CPUs in that mode...
- Daishiman 9y agodoes modern x86 even support real mode?
- niftich 9y agoSure it does. All x86 CPUs boot up in real mode, for example. Bootloaders are written in real mode.
- wolfgke 9y ago> Bootloaders are written in real mode. Not when the bootloader is an UEFI application. UEFI puts the processor into 32 bit protected mode or typically long mode (64 bit). So when your bootloader that is implemented as an UEFI application is started, you are already out of real mode.
- userbinator 9y agoAFAIK all x86 processors start in real mode. Intel tried making a 386 variant with only protected mode a long time ago, and it didn't sell very well: https://en.wikipedia.org/wiki/Intel_80376 https://en.wikipedia.org/wiki/Intel_80376
- yuriks 9y ago> We could get a >50% performance boost by ignoring security. What makes you believe that? The (crude, emergency, not designed-in) workaround dropping performance by 50% doesn't mean that fixing the issue in the design requires reducing performance by 50%.
- discoursism 9y agoIndeed. Google's published data suggests negligible losses if you are using FDO, which you must be if you care about performance.
- noway421 9y agoWhat is FDO? A quick google search doesn't result in anything meaningful.
- wahern 9y agoAre you referring to this? Performance Details Overhead Naturally, protecting an indirect branch means that no prediction can occur. This is intentional, as we are “isolating” the prediction above to prevent its abuse. Microbenchmarking on Intel x86 architectures shows that our converted sequences are within cycles of an native indirect branch (with branch prediction hardware explicitly disabled). For optimizing the performance of high-performance binaries, a common existing technique is providing manual direct branch hints. I.e., Comparing an indirect target with its known likely target and instead using a direct branch when a match is found. Example of an indirect jump with manual prediction cmp %r11, known_indirect_target jne retpoline_r11_trampoline jmp known_indirect_target One example of an existing implementation for this type of transform is profile guided optimization, which uses run time information to emit equivalent direct branch hints. -- https://support.google.com/faqs/answer/7625886 Note the parenthetical in the first paragraph. The way I read the above, they're merely saying that the performance is the same as disabling branch prediction for the section of code. Which would be really slow. But, presumably, faster overall than _actually_ disabling branch prediction as there's probably no good way to explicitly do that in as localized a manner.[1] And as I interpret this, the reference to FDO is unfortunately confusing and perhaps better placed under the heading of correctness. They're merely saying that the transformation of indirect branches to direct branches is something compilers already do to steer speculative execution down the correct path. Except in the case of a retpoline it's steering speculative execution into a trap. [1] I'm no expert in this area (nor do I do much assembly programming) but AFAIU branch predictors these days have substantial caches of their own. Disabling branch prediction or flushing the predictor's caches is probably much more costly than simply steering the predictor into a trap. The single pipeline bubble you create is better than the many bubbles that would be created if the branch predictor had to warm up again for later code.
- dewiz 9y agoIf you could design your own processors to run your only code and processing your only input, I’m pretty sure it would be 10x to 100x faster
- NegativeLatency 9y agoASICs and FPGAs do this. They're used in bitcoin mining where you do the same operation over and over.
- bitL 9y agoYou can already get 1,000x speedup in JavaScript if you e.g. avoid CORS on images where you read all pixels one-by-one. What should take a few ns in fact easily takes 30s in such an image. Security and performance are adversarial; we can have almost-perfectly secure systems that would make 8th gen i7 slower than Z80 or superfast CPUs where anybody can do anything.
- quonn 9y agoHow can CORS possibly be related to image pixels in any way?
- bitL 9y agoFor some reason every single pixel access must be authorized through CORS. I am not sure if this is in the standard or just shoddy implementation in all browsers. Try it yourself, read pixels in one non-CORSed image, and then in CORSed and wonder what went wrong on the drawing board. Some people bypass it via WebGL.
- DiThi 9y ago> Some people bypass it via WebGL. How? There's no concept of a tainted WebGL canvas because it just can't load textures without CORS.
- missblit 9y agoIt's to prevent reading cross-origin images through JavaScript. A canvas is considered tainted if it contains data from a cross origin image that was loaded without CORS approval. Tainted canvases cannot be read from by JavaScript. I don't think this requires a 1000x slowdown but I'm not super familiar with this area of the spec. It should be possible to cache the tainted state of the canvas in a single bit, only updating it when adding new images to the canvas, and checking the bit when converting the canvas to an array.
- jordanthoms 9y agoIt's more than that even - given that a high portion of the code being run now is using virtual machines, a lot of that protection is redundant. If all code is run inside VMs and zero 'native' code is allowed, then you could run without needing protection rings, system call overhead, memory mapping, etc - which in theory could more than make up for the virtual machine overhead. This was being explored with Microsoft's Singularity and Midori projects but seems to be a dormant idea. A fun talk on this idea with JavaScript: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- yjftsjthsd-h 9y agoIsn't that a unikernel?
- SolarNet 9y agoNo. Each copy of the VM is still it's own process. The kernel just trusts the VM to be safe.
- bestham 9y agoI don’t think it works like that. You still need protection between the rings inside the VM and the CPU is providing that protection. The VM is not only a user process for the host, it is executing its kernel code in the virtualized ring 0 on the CPU (where its still the CPU that provides protection).
- jordanthoms 9y agoAs i understand it, with this approach you wouldn't have a separation between kernel code and the virtual machine - everything runs in a single address space and you rely on the virtual machine verifying the code as it JITs it.
- tedunangst 9y agoAnd that, of course, is how you get Spectre.
- kayoone 9y agoDoesn't it also mean Intel kind of cheated their way to the performance crown by ignoring security while AMD does not seem to have these issues ? It certainly brings Ryzen closer again, however future improvements to the patch might make it negligible in the end.
- pishpash 9y agoAMD has the same issues. The difference in Meltdown, according to the paper, comes down to idiosyncratic peculiarities of timing differences, not anything fundamentally more sound in other processors.
- contrarian_ 9y agoWRONG. You fell for the Intel PR strategy. AMD is completely unaffected by Meltdown, since AMD checks permissions before fetching memory into the cache.
- wohlergehen 9y agoSection 6.4 of the Meltdown paper seems to indicate that the same flaw is present in AMD CPUs, but not easily exploitable. Do you have a different source for that?
- contrarian_ 9y agoThe toy example referenced in section 6.4 is actually closer to Spectre. It's missing the crucial distinction that the speculatively loaded address should belong to a page inaccessible from the current ring level. To see why that toy example is insufficient, consider that you could simply execute the load directly without putting an exception in front of it and you would be able to read the value.
- marcosdumay 9y agoMeltdown looks pretty much like cheating. Intel simply took security verification out of the critical path, and their public image ought to suffer for that. Spectre is a much more complex issue. It is more of a "I would never thing of that" thing. Looks like there were people at the security community talking about it even 10 years ago, but it is certainly hard for knowledge to spread to chip designers - most of what security people study would be noise for them, and even the security people mostly ignore those.
- pishpash 9y agoYou can get a performance of this magnitude because the baseline secure system is a hurried patch and wasn't designed for it. We're far from the optimal performance-security trade-off.
- zerokernel 9y agoEven dedicated supercomputer processors (e.g. A2, SW26010, VIIIfx) use virtual memory. In fact, most GPUs nowadays include an MMU as well, something they historically never had. (SC applications tend to be huge fans of using enormous page sizes, like 2 GB, which mitigates page table walk costs)
- DSingularity 9y agoNice thoughts but the vulnerabilities of Spectre and Meltdown do not directly threaten code which runs on the vulnerable CPU. Instead, the vulnerabilities allow malicious code running on the vulnerable CPUs to attack the system and other apps. A subtle difference, but makes the job to identify the applications which are not trustworthy and avoid running them on the performant but potentially vulnerable cores.
- egwor 9y agoIf every application were signed (like on the apple store), does that help reduce the risk here? If it were a game server then all apps run would presumably be provided by some official third party who could be relied upon to sign the binary. If it were all signed, then is the risk of the box becoming compromised fairly small and worst case, replacing the entire box (rebuild) if there were an issue could address problems quickly? [edit to make it clear that this is a question]
- lixtra 9y agoIf the application can run sufficient complex arbitrary code it is not safe. Example: Safari with JavaScript JIT compilation.
- bradleyjg 9y agoIt is my understanding that any sort of cloud setup would be completely out. Also, anything with a web-browser or other platform that runs third party code. But that still leaves an awful lot of servers that are under the control of a single company or individual and don't run any untrusted code (sandboxed or otherwise), doesn't it?
- amelius 9y ago> if you're running a game server you really don't have to care very much Think also about scientific computing, which usually doesn't need to be done in a secure multi-user environment (strictly speaking). I.e. you could limit security to the entrance gate (log in).
- twic 9y ago> We could get a >50% performance boost by ignoring security. Perhaps by making it unnecessary, rather than ignoring it - SPIN is now over 20 years old: http://www-spin.cs.washington.edu/ http://www-spin.cs.washington.edu/ There are other single-address-space safe-language systems that are even older; Genera is from the early '80s.
- lixtra 9y agoI assume those save language would still fail to defend against spectre. The problem is that the „code path with data“ executed in a speculative branch is not considered by the compiler but „fantasized“ by the cpu. Remember that Spectre can be exploited through JavaScript JIT. The JS sandbox is quite comparable to the models used for save languages.
- mtgx 9y agoNo, it just means that it's better to design chips and software architectures with security in mind from day one. If you don't, then every single patch you add afterwards will bloat-up the whole system and the (software) performance will drop overtime. It's just another way to say you're building technical debt into your chip/software if you don't consider security from day one. Because sooner or later you will need that security, if you have tens of millions or more people using that product. So it's not like you can just ignore it. You're just postponing it for later.
- akhilcacharya 9y agoI might be wrong, but isn't this what trading companies do on their network-insulated trading machines?
- javajosh 9y agoYeah, you split your business into those who's customers need >1 physical machine, and those that need < 1 physical machine. Drop security for the former, increase for the latter. Both can phrase their application as a unikernel.
- dfox 9y agoThe performance boost is not about ignoring security, but about ignoring edge case of one particular security check on i386 which ended up being the only critical one for "modern" unix-derived (which for purposes of this discussion includes Windows NT) OSes. In original x86 protected mode model (ie. real security flags on descriptor level and page protection bits only used for scheduling of paging) this would be non-issue.
- nickpsecurity 9y ago"What would the TempleOS of CPUs look like, I wonder?" In the old days, probably Burroughs B5000 for it being high-level with security and programming in large support built in before those were a thing. If about hackability, the LISP machines like Genera OS that you still can't quite imitate with modern stuff. If a correct CPU and you want it today, then I've been recommending people build on VAMP that was formally-verified for correctness in Verisoft project. Just make it multicore, 64-bit, and with microcode. Once that's done, use the AAMP7G techniques for verifying firmware and priveleged assembly on top of it. Additionally, microcode will make it easier to turn it into a higher-level CPU for cathedral-style CPU+OS combos such as Oberon, a LISP/Scheme machine, or Smalltalk machines. Heck, maybe even native support for Haskell runtime for House OS. https://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm https://www.smecc.org/The%20Architecture%20%20of%20the%20Bur... http://www.symbolics-dks.com/Genera-why-1.htm http://www.symbolics-dks.com/Genera-why-1.htm http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.217.2251&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.217... http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf http://www.projectoberon.com http://www.projectoberon.com
- nine_k 9y agoWhy limit yourself? Just run everything in ring 0. No kernel calls overhead at all. Lightning-fast network stack. Use a unikernel, run your trusted code only, don't store secrets. Beyond game servers, this could be the mode of operation of e.g. compute cluster nodes, relying on external firewall for security, and running zero untrusted code. Of course they won't care about meltdown or spectre either.
- devonkim 9y agoI’ve heard some rumblings that this is what some HFT shops were doing years ago to minimize latency and to reduce context switches. Because they already run bare metal and don’t share anything besides a physical facility with their competitors (if even that) the attack vectors are not the same as those running on shared machines either.