Another round of speculative-execution vulnerabilities [LWN.net]

Another round of speculative-execution vulnerabilities

Posted Aug 9, 2023 13:33 UTC (Wed) by butlerm (subscriber, #13312)
In reply to: Another round of speculative-execution vulnerabilities by eduperez
Parent article: Another round of speculative-execution vulnerabilities

Modern development techniques for web applications in particular have contributed to making application response time much worse than it used to be and orders of magnitude beyond what it was on much slower systems forty years ago. Wondering what went wrong and why no one seems to care if their page takes five or ten seconds to update is a relevant inquiry.

to post comments

Another round of speculative-execution vulnerabilities

Posted Aug 9, 2023 13:59 UTC (Wed) by yodermk (subscriber, #3803) [Link] (5 responses)

Yep, I often imagine a world where a large web application is written in Rust and runs as a single process on a single, vertically-scaled server. This bucks the "everything is a microservice" trend in a big way. But think of the benefits -- nearly every request could be served from in-memory in a single process. No Redis, no reaching out to other services for most things. Only requests that needed to result in durable, committed storage would have a slight delay. Besides that, operationally it would be dirt simple.

Main drawback is upgrades would require at least a bit of downtime. But, done right, it would be quite brief. The in-process caches would need to warm, though. The other drawback is the absolute need to be sure that no part of the system can crash under any circumstances. But Rust goes a long way in helping you there.

I'm learning Axum (a backend framework for Rust) and hope to be able to implement something like this someday.

Another round of speculative-execution vulnerabilities

Posted Aug 24, 2023 6:13 UTC (Thu) by ssmith32 (subscriber, #72404) [Link] (4 responses)

I dunno. Networks are pretty snappy compared to some of the systems discussed here - I would think a bunch of Rust microservices running on bare metal that correctly used HTTP would do fine. Vertical scaling is exactly what got us into the speculative execution mess. It's vertical scale to support the many many layers of abstraction to support whatever-the-hot language is to write a simple microservice.

But if you keep the services simple - why bother with all the abstraction? Give them full control, and make them fast.

The real troublemaker is not microservices or distributed systems - it's hosting providers wanting to resell the same time on the same hardware over and over again.

Another round of speculative-execution vulnerabilities

Posted Aug 24, 2023 22:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

FWIW, AWS doesn't share CPUs between multiple customers, except on a couple of very cheap instance types (T2 and T3 instances). I believe the same goes for Azure.

Another round of speculative-execution vulnerabilities

Posted Aug 25, 2023 9:58 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

Couple of questions:

Is this documented by AWS anywhere? I can't find it in their official documentation, and the instance types documentation just says "Each vCPU on non-Graviton-based Amazon EC2 instances is a thread of x86-based processor, except for T2 instances and m3.medium.", which implies that two vCPUs assigned to different customers can be on the same core, just not using the same thread.
How is the "each CPU core can only be used by one customer" enforced? Is it just relying on the kernel rarely migrating actively used vCPU threads between hardware threads, or is there scheduler affinity etc applied to enforce it?

Another round of speculative-execution vulnerabilities

Posted Aug 25, 2023 19:27 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

AWS documentation is a mess, but it's documented: https://docs.aws.amazon.com/whitepapers/latest/security-d...

> Fixed performance instances, in which CPU and memory resources are pre-allocated and dedicated to a virtualized instance for the lifetime of that instance on the host

FWIW, this design has been used from the very beginning. Even with the old Xen-based hypervisor, there was very little sharing of resources between customers. AWS engineers anticipated that the hardware might have issues allowing the state to be leaked between domains, so they tried to minimize the possible impact.

> How is the "each CPU core can only be used by one customer" enforced? Is it just relying on the kernel rarely migrating actively used vCPU threads between hardware threads, or is there scheduler affinity etc applied to enforce it?

CPUs are allocated completely statically to VMs. The current Nitro Hypervisor is extremely simplistic, and it is not capable of sharing CPUs between VMs.

Another round of speculative-execution vulnerabilities

Posted Aug 25, 2023 19:33 UTC (Fri) by farnz (subscriber, #17727) [Link]

Thanks for the link - it answers my question in full, and makes it clear that this is something that's architected into AWS. And yes, AWS documentation is a mess - it looks like I didn't find it because I wasn't looking at AWS whitepapers, but at EC2 documentation.

I had hoped that it worked the way you describe, because nothing else would meet my assumptions about how security on this would work, but I have had enough experience to know that when security is involved, hoping that people make the same assumptions as I do is a bad idea - better to see my assumptions called out in documentation, because then there's a very high chance that Amazon trains new engineers to make this set of assumptions.

Another round of speculative-execution vulnerabilities

Posted Aug 11, 2023 0:04 UTC (Fri) by khim (subscriber, #9252) [Link]

> Wondering what went wrong and why no one seems to care if their page takes five or ten seconds to update is a relevant inquiry.

That one is easy. There's just no one left who may care.

Everyone is trying to solve their own tiny, insignificant task. And the fact that when all these non-solutions to non-problems, when combined, create something awful… who may even notice that, let alone fix that? Testers? They are happy if they have time to look on the pile of pointless non-problems in the bugtracker! Users? They are not the ones who pay for the software novadays. Advertisers do that and they couldn't care less about what users experience.