Another round of speculative-execution vulnerabilities

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.

@Wol You've mentioned Scarlet before, do you have a link where I can learn more about it?

Ditto for Pick, what is it, link? Thanks!

> You sound very much like a ZX Spectrum user!

Yes, that was my fist "computer", back when I was fourteen.

Maybe it's more a combination of control flow being predictable and memory latency being unpredictable. Compilers (AOT and JIT) can have a go at predicting control flow using PGO, but I suspect it's largely impossible for them to predict which memory loads will come from L1 (~5 cycles) and which will come from RAM (~300 cycles) as that depends heavily on the dynamic state of the caches. That unpredictable latency prevents a compiler from doing good instruction scheduling by itself, so it has to rely on the CPU doing dynamic scheduling that can adapt to the actual latency of every single memory access. And the CPU can do that because the highly predictable control flow means that while it's waiting for RAM, it can speculatively gather hundreds of instructions to reschedule and execute out of order.

If memory latency is predictable then I think it's much easier for the compiler to statically schedule the instructions, and the CPU can be much simpler while maintaining decent performance. But that only seems practical with very small amounts of memory (e.g. microcontrollers with single-cycle latency to SRAM, but only hundreds of KBs) or very large numbers of threads (e.g. GPUs where each core runs 128 threads with round-robin scheduling, so each thread has 128 cycles between consecutive instructions in the best case, which can mask a lot of memory latency), not for general-purpose desktop-class CPUs.

> don't see that this has much to do with the programming language. Rust is as vulnerable to Spectre and Downfall as C is AFAICS.

You're thinking much too narrow here in terms of what "C" is in this context. It's has far less to do with the specific syntax and more with the general model of computation that derives from the original PDP11, i.e.:

Programs are a series of commands, whose effects become visible in order from top to bottom. The sequence of these commands can be arbitrarily replaced using a specific command, called a "branch". There is a singular, uniform thing called "memory", which is numbered from zero to infinity and you can create a valid read-write reference to any of it by using that number. And so on.

None of this is true internally for any modern compute device. It isn't even true for C anymore. But it was true for the creators of C, and as a result these assumptions were baked very deeply into the language, then tooling like gcc and LLVM, then languages that use that tooling like Rust, OpenCL, CUDA, and then architectures that wanted to be able to easily targetable by those tools like RISC-V and, most notably, AMD64. (As opposed to it's Itanic cousin). It's so established that people don't even recognize these as specific design choices anymore, it's just "how computers work".

Rust is definitely a step away from C, and one that has at least some potential to improve how chips are designed in the future, if the tooling allows for it. But it's not a very big step in the grand scheme of things.

Way OT now, but using wood for power, on the back of a highly oil based system to grow, process and transport (over massive distances) that wood is not that green.

Particularly if that wood is coming from old wood forests that are being cleared. I don't know the details of Canadian wood pulp, but IVR a lot of their wood is from clearing old woods.

A final issue is that commercial forestry (least in UK and Ireland) is from dense pine forestry plantations, which is kind of a disaster for the native ecosystem. Really, we need to reforest our denuded countries (UK and Ireland) with natural, long-life forests - really good carbon capture and storage!

Which means we need something else for power. Something that is a lot more space efficient than covering the country in dense commercial and largely dead pine forests (which probably still won't give us enough fuel). The answer is obvious, but greens have irrational dogma.

I also tried Java to try to make use of the Niagara, a major pain point was a number of non thread-safe routines in the standard library.

Especially annoying since I was not making these calls directly, they were from third-party libraries so it was practically impossible to figure out what could be safely run in parallel.

I'm not sure Java was its natural habitat either, given the GC issues. It was designed for fairly parallel (multi-thread/process) C/C++ server software - web, SQL, etc.

Tilera, worked on software on that too. The people who architected that software had actually done a pretty good job of making sure the packet processing "hot" paths could all run independently, and each thread (1:1 to CPU core) had its own copy of the data required to process packets. Other, non-forwarding-path "offline" code would then in the background take the per-CPU packet data, process it, figure out what needed to be updated, and update each per-CPU hot-path/packer-processing data state accordingly. That worked very well.

The issue the shop I worked at had with Tilera was that it was unreliable. The hardware had weird lock up bugs. I figured out ways to increase the MTBF of these hard lock ups, by taking more care in programming the broadcom Phys attached to the chip (I think they were on ASIC, and part of the Tilera design - can't quite remember). But... MAU programming via I2C controllers shouldn't really be causing catastrophic lockups of the whole chip. We still had hard lock ups though - never fully figured them all out or work-arounds.

It seemed a 'fragile' and sensitive chip.

Was also there, did that - went from a Niagara beast machine to Ubuntu VMs. Our actual reason was to get away from Oracle as absolutely fast as possible - but it turned out bogomips were what our apps actually wanted, and 300MHz vs 3GHz did in fact make our apps many times faster.

PHP and other scripting languages like Perl treat numbers as double-precision floating point but a lot of the time they are only smallish integers in practice. With a small amount of silicon you could give each core a 'fake FPU' that performs the necessary integer operations. If it turns out the inputs or the result aren't integer, it waits for the real FPU to become available.

I think that can be solved by writing constant-time code when you're dealing with sensitive data, so it's never exposed to the branch predictor side channel, which you should be doing anyway to avoid other timing attacks. The problem with Spectre is that it can't be solved by writing perfectly correct side-channel-free code, because the CPU is not executing the code you wrote, it's executing some arbitrary code that you *didn't* write (when it's speculating past a misprediction), and that unwritten code may expose the data to side channels. Software developers can't take responsibility for code they didn't write, so it becomes a hardware issue.

Hmmm, I've understood the issue to be explained by the telegraph equations: https://en.m.wikipedia.org/wiki/Telegrapher%27s_equations, but I suppose at the latest processes they may possibly need to account for individual elections. Which would be an extra complication.

With my physicist pedantery hat on, no, I don't think that's exactly right. Now, my specialty was never high speed small scale circuits so I could talk out of my ass, but anyway; The speed of light in a conductor (that is, the velocity with which the electromagnetic wave propagates in the medium) is about 2/3 of the speed of light in vacuum, including for very narrow conductors. That is, very very fast. Similarly, the electron drift velocity also remains as it is for larger conductors, that is very very low, on the order of um or mm/s.

What changes then is that for these very small conductors you'll find on modern deep submicron integrated circuits, the relative capacitance of the conductor starts to rise (and the resistance doesn't go down as well as you'd like either). This leads to a phenomenon where when you apply a voltage on one end of the conductor, it takes longer until the voltage/current rises enough on the other end to be registered as a 0->1 flip. So in effect it appears as if the speed of signal propagation drops. I'm not sure how well the telegrapher's equations mentioned by malmedal in the sibling post applies to multi-GHz signals propagating in these very narrow conductors, but something like that is the gist of it. I don't think you need to apply quantum mechanics or study the behavior of individual electrons per se to understand this phenomena.

So, as farnz says, you appear to have completely mis-understood my argument and are arguing against a straw man.

Signals are carried by photons (or em waves, same(ish) thing) so the speed of light IS relevant, although from what others have said the telegraph effect is probably more important, and

My argument has repeatedly been prefixed with "IF components need to communicate" so okay, I'm not necessarily talking about clock cycles, but a single communication cycle has that upper limit. I'm not always clear in what I say, I know that, but if you make no attempt to understand me, I can't understand you either. So IFF a communication cycle equals a clock cycle, 5GHz is the maximum clock possible between two random components in a chip. Of course, splitting a communication clock cycle into multiple clock cycles can speed OTHER stuff up, but it makes no difference to the speed at which a signal travels across a chip.

(And of course, without communication a chip can't work.)

Cheers,
Wol

Another way to think about it: these signals are largely one-way communication. If it were round-trip, the speed of light would matter. But all that really matters is how accurately you can sample the wire for a signal (PCIe gen 6 can apparently do so 64 billion times a second).

And another way to sanity check things: if the size of space between communication endpoints limited your processing rate, we'd probably still be waiting for the first (quality) images from various Mars rovers.

At least I think that's somewhat closer than what Wol has as a model.

It's amazing how far they have pushed the technology, just ten years ago I would have said it was impossible to get that high outside of a lab-setting.