The Brutal Performance Impact From Mitigating The LVI Vulnerability

[dave_boo]

But lots of the Intel vulnerabilities are of a kind where code in a VM can get access to information outside of the VM, so a VM only mitigates some vulnerabilities. This really is a big problems because cloud servers likes to use VM, Docker, ... to share the machine among multiple customers. While JS is an example where home users are sharing their computer with unknown others.

So spin up a VM and install a VM inside of that? So if they break out of the VM they've only reached a VM that's hosting it and would have absolutely nothing of value.

It's only for web browsing so the required resources should be light.

Or am I way off base? I don't consider myself to be important enough to try and run an attack against; especially since all banking and other transactions are done in person but rather this is a theoretical exercise for me.

[Ape22]

A thin client situation or some type of shared access multi-VM setup is what I've seen described. Direct physical access should not be confused by direct access to machine.

[zyxxel]

So spin up a VM and install a VM inside of that? So if they break out of the VM they've only reached a VM that's hosting it and would have absolutely nothing of value.

It's only for web browsing so the required resources should be light.

Or am I way off base? I don't consider myself to be important enough to try and run an attack against; especially since all banking and other transactions are done in person but rather this is a theoretical exercise for me.

Alas, it isn't any security break that a second layer of VM solves - many of the side band attacks makes the code able to collect statistics about what happens in the rest of the processor for any part of computations that doesn't contain some barrier code to flush/dual-load/random-delay/... The only solution is to either make all accesses constant time (i.e. making our processors 10+ times slower), making it impossible to measure time with a reasonably high precision, making sure the processor doesn't leak cached information etc. But it's hard when the processor itself besides multiple layers of cache and speculative evaluation also have hidden register banks that keeps state. So the better way is probably to separate our code into two categories and have the sensitive part run in a slow but screened processor. In the end, the huge majority of CPU cycles are performing actions where the leaks aren't important. Side channel attacks that relies on timing requires that you have a loop where the attack can collect measurements again and again to get the data points required to predict what data the rogue code is stealing.

When compiling code, the loops are inside the compiler while the compiler constantly processes new source code data. So it isn't normally that easy to steal the source code data. But when decoding a video, the loop contains the decryption key for the DRM. And if you can figure out the DRM protection, then the rogue code can then decode the video stream itself, making the DRM irrelevant. And this is why some tasks needs lots of protection by source code rework and by microcode fixes etc. While lots of other code doesn't need to worry that much.

But right now, the processor does not know which code is sensitive and which isn't. So a general fix will make all programs hurt, just because it is imperative that a side band attack will not let a rogue program figure out a TLS or SSL secret. Side band attacks will continue to hurt us for many years to come. And for basically all smart/fast processor architectures.

[Kafein]

Interestingly this rain of architectural vulnerabilities can be traced back to... AMD.
Their 64 bit variant of x86 called AMD64 became the defacto standard x86 architecture as back then Intel was slow on the ball.
Intel and HP did develop a competitor which was... Itanium.
That is, an architecture which by design couldn't have any of the speculative execution vulnerabilities we're discovering now.
Obviously Itanium had its own set of problems which lead to Intel basically abandoning it now.

[zyxxel]

Interestingly this rain of architectural vulnerabilities can be traced back to... AMD.
Their 64 bit variant of x86 called AMD64 became the defacto standard x86 architecture as back then Intel was slow on the ball.
Intel and HP did develop a competitor which was... Itanium.
That is, an architecture which by design couldn't have any of the speculative execution vulnerabilities we're discovering now.
Obviously Itanium had its own set of problems which lead to Intel basically abandoning it now.

First off - the vulnerabilities aren't related to the instruction set but to the way the pipelines, caches and registers works when executing the instructions. So you can't blame AMD. Take an old Z80 and give it multiple cache layers and a floating pool of registers and a pipeline that allows reordering and where the Z80++ handles 2-5 instructions/clock cycle instead of one instruction per 4 cycles at several times higher speed than the RAM can handle and you would get the same problems.

Next thing - Itanium wasn't the only 64-bit project Intel worked with. Just one they decided wasn't meaningful to continue with. Besides the Itanium, they did develop their own 64-bit x86 instruction set. Just that they were too slow - when they went to Microsoft requesting support for their own 64-bit x86 processors, Microsoft said they refused to support two 64-bit x86 dialects. So Intel then had to take the AMD instruction definitions and give then their own name. Intel then presented it as their own new instruction set at a nice press conference. And for the following years, people have been confused why Intel with their new 64 bit instruction set runs Linux builds with amd in the instruction set name.

Anyway - the problem isn't because of how you lay out the bits to encode a specific instruction or address a specific register or select a memory addressing mode.

[Kafein]

First off - the vulnerabilities aren't related to the instruction set but to the way the pipelines, caches and registers works when executing the instructions. So you can't blame AMD. Take an old Z80 and give it multiple cache layers and a floating pool of registers and a pipeline that allows reordering and where the Z80++ handles 2-5 instructions/clock cycle instead of one instruction per 4 cycles at several times higher speed than the RAM can handle and you would get the same problems.

Next thing - Itanium wasn't the only 64-bit project Intel worked with. Just one they decided wasn't meaningful to continue with. Besides the Itanium, they did develop their own 64-bit x86 instruction set. Just that they were too slow - when they went to Microsoft requesting support for their own 64-bit x86 processors, Microsoft said they refused to support two 64-bit x86 dialects. So Intel then had to take the AMD instruction definitions and give then their own name. Intel then presented it as their own new instruction set at a nice press conference. And for the following years, people have been confused why Intel with their new 64 bit instruction set runs Linux builds with amd in the instruction set name.

Anyway - the problem isn't because of how you lay out the bits to encode a specific instruction or address a specific register or select a memory addressing mode.

Architectures vary in many more ways than instruction sets, and some designs are more amenable to simpler implementations, while others can only exclusively run fast with deep pipelines. AMD64 was not designed with avoiding out-of-order execution in mind (that can be traced back to the roots of x86, though of course at the time the problem was vague and distant if known at all), whereas Itanium was, and there lies the crux of the issue.

[skeevy420]

Sucks to be trying to sell "hostless lambdas" or whatever the cloud geeks think is cool at the moment, and it seems that running contemporary JavaScript on the same machine that handles your secrets and does your real work might not be such a good idea, but I don't think that this is the end of the world. The problem, such as it is, arises from letting malicious code share hardware that has lots of hidden (non-architectural) state, (because it turns out not to be very well hidden). Seems obvious that rather than slowing the machine down by orders of magnitude, by preventing any of that hidden state from doing its job, the much better approach would be to just keep the malicious code somewhere more isolated, where it can't see the hidden state of other code. That may require operating system changes, so that task switches don't just swap visible register state, but do some more work to flush that hidden state, at least when switching between different "trust" domains. That is: you can separate in time, and you can separate in space. Modern processors are growing cores like rabbits (those new Amazon Graviton2, for example: 64 single-threaded cores) so much more often threads will not have to time-slice at all, they'll just spin up another core and own it for the duration.

Oh, and the good old rule of not running malicious code in the first place seems like a keeper, too. Besides sticking with open source, and being careful around the trust of your sources when you can't. Surely it's not beyond the wit of man to detect code that spends a lot of cycles doing nothing obviously useful while looking at the high-res clock, and just knocking it on the head? Perhaps deciding that an advertising-sponsored browser plugin or mobile app might not be a great idea after all?

Silverblue for desktops and CoreOS for headless.

oooOOOOooo, it's neat, new, and shiny aren't the only reasons I moved to Silverblue

What you describe is exactly the workflow and style of computing that those operating systems promote, document, and use.

It even promotes Flat usage over what's in the package manager...though I'll be the first to admit that Flat is still lacking in areas and, IMHO, isn't quite ready for mass adoption yet. Flats are perfectly fine for us Phoronix geeks, but I wouldn't recommend them to my extended family due to not wanting to be their tech support. Ditto with Silverblue -- great for geeks; needs more polishing for not geeks.