Don’t forget about JavaScript, a common way for people to run untrusted code on their computers. Not all of micro-architectural data sample are exploitable in JavaScript, but some are.

If anyone can show a proof-of-concept ("this page grabs your password manager extension's data") I'll eat my words. But I feel confident that most of these issues are purely academic and, while interesting, serve more to provide content for PhD theses than represent urgent hazards on the web.

In other words, if I choose a process on my system at random, and dump a few dozen bytes from it, I can technically claim to have leaked some data; but the use of that data to an attacker likely depends strongly on factors which are outside of the attacker's control. It's somewhat like finding a (real-world) key on the ground: you theoretically now have access to something you shouldn't have, but you have next to no idea what that something is.

But I feel confident that these issues are purely academic and, while interesting, serve more to provide content for PhD theses than represent urgent hazards on the web.

They also provide content for sensationalist clickbait articles and fuel the paranoia that drives society towards authoritarianism and furthers the war on general-purpose-computing, which IMHO is a much bigger issue to worry about.

Only PoC says very little. If I were head of a nation state APT I'd look into exploiting this because attack surface of JS is high. I'd only use it targeted, for example on Microsoft Azure team as outlined in Darknet Diaries #78.

If they’re targeting Joe and Jane Average, the long history of government tech procurement failures means I expect them to fail — fail dangerously, but fail.

This thread discusses SAB (shared array buffer) and Wasm side channels https://github.com/tc39/security/issues/3

I believe it is going towards JIT being disabled, or most severely limited.

Javascript bloat exists because of a social problem: the guy who fixes the corporate webpage's javascripts is called a "webdesigner", and "webdesigners" are the lowest rung on the corporate IT ladder, maybe only a bit above first-tier techsupport.

If you want to make some sort of career you need to upgrade from "webdesigner" to "frontend developer", and that means cryptic, incomprehensible and pointless "frontend frameworks".

It provides to value to business or users, but management puts up with it because it fixes the problem of employee churn. (Frontend positions are a big pain in the ass.)

Since that isn't getting fixed any time soon, most people have tried to take matters into their own hands, with varying degrees of success.

It would go away in short order if Google rankings severely penalised it.

JS bloat exists because HTML Working Group along with the whole industry believes JS is the solution to everything. They believe everything on the web should be Web Apps, and completely neglect Web Page development. It was only in the recent 2 two years did we start seeing discussions to reverse course.

Never trust the tech industry to make optimal decisions, you are only in for a bad time.

They can set metrics on quality, but those can be easily gamed. (E.g. measuring average TTFB for a site instead of the real wall time to show visible content for the user.)

Project management _definitely_ has the power to dedicate time to fixing performance issues.

Metrics can be gamed, but certain metrics - such as time to interactive, and time to fully loaded - are fairly well in line with what users actually care about. Even if they're gamed, a project manager can say, "This still feels slow to use. Dedicate the next (sprint|cycle|month|whatever) to performance work."

This actually excites me. When the foundation is shown to be rotten, it's time for a new foundation.

I'm optimistic, though, that the future holds a fork, with some devices insecure-but-fast and others secure-but-slow. Because there's a market for both. I don't care if my gaming hardware is vulnerable to Spectre because ideally there's nothing worth stealing there anyway. Email/messaging hardware can afford to be a -lot- slower than my gaming rig without any appreciable impact on the experience.

Perhaps the future holds motherboards that look like the physical embodiment of Qubes OS, with secure and insecure chips running compartmentalized features based on their security/speed requirements. We already do something like this for performance with the divide between CPUs and GPUs.

A major advantage of not adopting new CPU designs for a while is that you get to keep insecure-but-fast and secure-but-slow behavior in the same CPU by simply tweaking mitigations.

It'd seem both theoretically and practically possible to engineer hardware that could enable and disable certain optimizations and extensions dynamically.

(note that energy consumption may also be a related factor here)

The safe execution of any untrusted Turing complete code is a pipe dream.

You, at least, need a clean sheet CPU design starting from ISA, and basic logic operations formally validated against instruction level analysis to have a fighting chance.

But even such chip do get pwned, as shown by key recovery from credit cards in the wild.

I don't think that's true. It's not turing completeness that's the real problem here. It's that software usually has access to accurate timing information, whether it's via RDTSC, gettimeofday(), or sharing memory with another thread that does things that take a predictable amount of time. If a program has no notion of current time and cannot measure how long something takes, then a lot of those side channel attacks no longer work. (Note that this precludes using styles of threading that have nondeterministic results, but it doesn't preclude using styles of threading that are deterministic, like Haskell's parMap.)

I do think maybe we should move away from the model of "let's let people run programs comprised of arbitrary instructions on their computers, and build all our security around keeping programs from reading and writing things they shouldn't" to a model of "all programs running on this computer were compiled by a trusted compiler, and our security is based on the compiler disallowing certain unsafe constructs". This is sort of analogous to web browsers running javascript in a sandbox, or running eBPF in the Linux kernel.

harvard architecture - code and data are separate things

They're talking Von Neumann with a special "blessed" tooling written to not produce behaviors that would let users do nefarious things. They want to reduce the space of possible computations from arbitrary to "only these patterns which are provably safe".

Essentially, they want to hobble the user (malicious or not) and force good behavior by giving them tools that are incompatible with malicious behavior. They want Asimov's Three Laws of Robotics for computation.

The issue being, you run into Halting problem real fast when trying to make that blessed toolset. How does it recognize malicious code or bad series of individually benign, but collectively malignant opcodes? Remember, side channels like Spectre and Meltdown boil down to timing how long it takes for a computer to say "no", and then for you to access a piece of data you know should only be cached if the conditional that was preempted by an access violation was one value or another.

That is, start timer -> run (expected to raise access violation) conditional, branch speculative load -> access check -> exception -> check for result value in cache -> stop timer -> rinse -> repeat

Each of those is a benign command that could be sprinkled in anywhere. Collectively, they are a side-channel. You could still make variations of the same setup by tossing in junk values in between the necessary steps that would avoid this blessed tooling's (assumed) unwavering pattern recognition. I wouldn't actually use a compiler to stop this. You'd use a static analyzer to recognize these combinations; and even then, there's a lot of timer -> thing -> timer stop -> check programs that aren't malicious at all out there.

The answer with computers has been "if it absolutely must remain secret, implement security at a higher level than just the computer". Everyone should know that if you've got access, the computer will do what it's told to do.

The poster's suggestion is a pipe dream; and a dangerously seductive one at that, since anytime you hear from the "Trusted/Secure Computing" crowd, it almost always means someone wants to sacrifice everyone else's computing freedoms so they can write something they can pretend to guarantee will work.

Sorry, the cynicism leaked in a bit at the end there; but I have yet to see a security initiative that does anything but make life miserable for everyone except security people. I'll put up with some unsafe behavior in order to keep the barrier to entry low for the field in general; and accept the cost of more rigid human centric processes to make up for the indiscretions of the machine. Keep abstraction leakage in check.

The safe execution of any code requires an operating environment that never trusts the code with more than the least privilege required to complete a task. It has worked in mainframes that way for decades.

The IT zeitgeist these days makes me sad. Things can be better, but almost everyone is pushing in counterproductive directions, or has given up hope.

It has nothing to do with any OS level security features. We are talking about things happening below the level of what software can see.

You just cannot see any sign of such attack by looking at any register the OS can see.

Eliminating timing vulnerabilities is necessary to allow potentially-hostile workloads to share hardware, but it is not sufficient.

Instead they measured CPU temperature through frequency drift measured through change of network packet markers. A bit contrived but they made it workable quite reliably.

--

[1] https://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf

in other words, any system with more than one "task" running concurrently?

Yes, there are definitely workloads that will benefit from better hardware, e.g. video transcoding or pure number crunching, but i would contend that most websites, databasing, ci, &c could be done on something like a pi replacing a vm or 3 (of the same customer).

I don't have hard numbers, but I wouldn't have thought it would be all that dramatic.

As for price competitiveness, some customers might be ok with paying for the increased security.

However attempting to do so is multi year, for modern CPUs certainly multi decade project. This is not feasible as long as Moore's Law goes on.

Formal verification of kernels (SEL4) and a micro processors it runs on have been performed together to proof properties.

Large ALU blocks and vector units (such as multipliers) can be formally verified.

However efforts of end-to-end formal verification of entire processors won't happen unless there is demand to justify the huge investment of engineering resources and the market would be fine with chips many years behind.

Unless everyone is running dozens of clients on all their hardware it is cheaper to give everyone their own machine instead of investing the engineering time in to verifying chips. The economic incentives for Intel that selling more machines for isolation brings them more revenue without having to make investments in to decade long verification projects means it is not a mathematical certainty that it can't happen but just an economic one. After all speculative execution is just extra state and extra logic which can be formally verified. After all programs are just bit patterns and all quarters can be addressed in the formalism of Quantified Boolean Formulas.

But nobody is gonna undo 20 years of performance. You will just be told to buy more machines to isolate workloads.

In the grand scheme of things, high-intensity tasks are only infrequently high-security tasks - those two sets of workloads are mostly disjoint. So the long-term solution is to have "fast cores" and "secure cores".

The fast cores can have all the OoO, speculation, all of that good stuff. That's where you run anything that needs to go fast, or anything running "trusted" code. By and large, nobody cares if an ffmpeg process or HPC node might leak data. Databases? You control the queries that are running on them, right? There are some edge cases like video games where leaking data is moderately harmful (could be useful for exploits if you can reliably leak useful data) yet you still want maximum performance, but at the end of the day leaking data at a couple kB/s usually isn't going to be the end of the world especially if the data is rapidly changing.

If the code is untrusted or user-generated, or the data is sufficiently sensitive, then run it on a "secure" core. The "secure" cores have to be in-order, non-speculative, all that crap. Probably non-SMT as that seems to be a bottomless pit of sidechannels as well. But usually, you aren't churning huge workloads in the "secure" situations. You can still have crypto acceleration instructions built into the cores, AVX, whatever, just not speculative. It's probably better to get them fully out of the "normal" cache hierarchy as well.

There are a couple obvious problems here, but much smaller than trying to fix everything for every use-case. In particular web browsers are running untrusted code, and every single website is running 15 mb of shitty javascript code. It sucks but it's basically become an inner platform and you can't trust the code that it's bringing in, so that needs to be permanently isolated on its own secure cores. People will have to start paying attention to the performance of their javascript and optimizing out the real shitty bits.

Another big one is shared hosting environments - VPS environments are a prime target for trying to leak data from other clients on the same core/cache hierarchy, so those either need to be moved to "secure" cores, or switched to a model of renting out a whole core (or moved to a "hard time slice" where when the slice goes active you get the whole core for X seconds, then the processor stops, flushes everything, then switches clients). But VPS could conceivably be moved to "arrays of little cores" (to the extent that they aren't already) and that won't pose much problem for a lot of typical "micro" use-cases as long as every instance doesn't hit the server at once. Maybe for people that need faster than a dedicated "little" core the next increment becomes leasing the whole core, or even the whole complex of cores on that cache hierarchy.

Web application servers (not necessarily databases) are another one, unfortunately, since you can time web requests and use that to "leak" data down different code paths. If it's a directly user-facing service, probably best to get it onto a secure core.

The big task for humans is going to be identifying what stuff is allowable to run on the "fast" cores, and then get the schedulers set up so they understand that some stuff can only run in certain processor domains. It's not insurmountable, it just is going to take some time to plug away at it. Perhaps distribute whitelists, and allow the end-user to manually override it if they're really sure.

But yes I've been saying that too, my suspicion is that basically all of OoO and speculation is fundamentally incompatible with not leaking timing data between processes, and that the harder we tilt at this the more attacks we're going to turn up, it's going to turn into an endless game of whack-a-mole and it's going to eat up all the performance gains that we've spent the last 20 years building on the backs of OoO and speculation.

AMD is quite well-placed for this imo since each CCX basically acts like its own NUCA (non-uniform cache architecture) domain and they just happen to share a memory controller. That's pretty much the design you need to make it work right, just with big and little CCXs instead of only big. They just have to come up with their own little cores. Intel is going to be harder because the classic Sandy Bridge architecture (which is largely unchanged today) has all the cores collectively sharing their last-level cache, and I think that's probably a problem in the long term too. I think Skylake-X still works on the principle of cache being attached to each core and them talking to each other to share it.

AMD and Intel engineers, please make your consulting checks out to 'cash'. Thanks! ;)

I can’t seem to shake the notion that this idea of transparent, multi-level caching might have to go away too. That cache shared between cores may have to morph into a layer of chip-local memory that you allocate imperatively. It’s possible that languages like Rust or VMs like the Beam could either adapt to such hardware with fewer problems, or even leverage it. We keep trying to pretend like memory is flat but now we’re up to 3-4 layers of cache and memory banks. How much longer can you torture that abstraction?

The most intense thing my phone does is decrypt my password database, and it does this dozens of times a day.

And ideally that stuff could be moved into an on-processor secure enclave, so it's not executing on general cores at all. That way you straight-up can't even get to the data to try decrypting it, it just stays inside the enclave and the enclave doles out a single password at a time if and only if the password matches.

My guess is that one Tiktok video consumes far more CPU cycles than decrypting dozens of passwords.

I see alot about private keys etc etc, but is just a blind attack? Or do you need more info on the target? How quickly can you attack to get info?

In essence, is this something Joe Public needs to worry about their $5 vps, or something nefarious using against $CORP's public cloud infrastructure?

That said, its a pretty amazing time if you're a computer architect since you now have the transistors to spend on pretty much any crazy scheme you can dream up. So perhaps we'll see 'code safe' computer architectures emerge.

I don’t see why. Cloud providers have been offering dedicated hardware for a long time. If this problem isn‘t reliably fixable then more customers will make use of these options.

Completely agree about SpecEx. That's a misfeature that needs to die.

The challenge is more how to make a fast CPU like that.

For my money we’d end up going toward many-core with loads of simple in-order cores on a die. It’d almost look like a GPU. With 5nm how many in-order ARM or RISC-V cores could you put on a chip? You’d also probably move away from shared caches toward each core having more cache and processes having stronger core affinity. That would be both faster and less likely to allow cache timing attacks. You’d have so many cores a core per process would be feasible with sharing only happening at saturation.

Another direction would be to go back to trying to crank up clock speed with some new approaches. What could we do with today’s manufacturing techniques if we focused on faster transistors more than smaller ones? AFAIK almost nobody has been working on this since the game has been to use more transistors to implement more features and hacks instead.

I read about 10ghz parts on the lab bench in the 2000s. That’s eternity ago in terms of semiconductor process. A 10ghz in-order core would be like a 4X parallel 2.5ghz core… roughly… but more secure and broadly faster on code that’s hard to parallelize. Get rid of speculation and instead give it low branch latency and a ton of on board cache.

Plenty of smart people spent lots of money trying it and as it happens the physics doesn't work out. There are countless articles explaining why processor clock speed isn't increasing, e.g.

- https://www.maketecheasier.com/why-cpu-clock-speed-isnt-incr...

- https://software.intel.com/content/www/us/en/develop/blogs/w...

That helps with multitasking and parallel-friendly workloads, but lots of stuff isn't easy to make multithreaded.

As a counter example, how about the 8086?

Yeah, because they didn't realize how terribly the power consumption / heat output would scale; a 10GHz CPU will just melt itself.

Tesla, it was claimed, discovered something called "cold electricity" -- that is (according to the claim) -- when you ran it through a circuit -- it cooled rather than heated the circuit!

Now, today we have something sort of like this as thermocouples/Peltier Junctions (see https://en.wikipedia.org/wiki/Thermoelectric_cooling for more/better info on this) -- although it is not known if Tesla's "cold electricity" -- was talking about this effect and/or related -- or not.

Nonetheless -- it seems to me that IF (and it's a big if!) -- IF Tesla's "Cold Electricity" existed, IF it could be rediscovered, and IF it could somehow be integrated on a CPU either as part of or as auxilliary to the main CPU circuitry -- then the CPU cooling problem could be solved(!) -- or at least mitigated somewhat, to the point of allowing/permitting CPU's with higher thermal envelopes/tolerances/CPU speeds...

Again, there are some seriously big IF's there -- but I think it would be a great place for someone to do more research, or for researchers that might have an interest in this area...

It seems to me that Intel and AMD (or heck, any chipmaker for that matter!) -- might (or should!) -- have an interest for more research in this area...

In thinking about it -- It seems to me that there might be a relationship between heat, resistance, and unbalanced capacitance in a circuit...

In other words, you have a wire.

You put amps (at a specific voltage) through this wire.

If the wire diameter can't handle those amps (at that voltage, remembering that the higher the voltage -- the more amps that a wire of a given diameter can carry, case in point, high-tension electric transmission wires -- they usually never melt despite carrying huge amounts of electricity, the reason being that that electricity is at high voltage)

If the wire diameter can't handle those amps at that voltage (the the lower the voltage, the more it will heat at a given amp load), then it gets hot.

It starts to act less like a conductor -- and more like a resistor...

But wait!

Haven't we also seen this effect with capacitors that are fully charged (well, minus the heating)?

No longer does current pass through them at full capacitance -- as full capacitance is approached, they start to act less and less like conductors, and more like resistors!

They also want to "push back"!

Well, maybe wires which are under electrical stress (heating up, gaining resistance) act sort of like "mini-capacitors"!

That is, their capacitance isn't that much -- but they want to "push back" against the circuit, if only for a microsecond -- to release their micro-capacitative electrical load!

But -- in many places in a CPU -- if a bit needs to stay set to '1' for example -- this cannot happen -- because electricity needs to pass through that circuit constantly!

Solution: First, figure out a way to store bits in capacitatively balanced circuits (an LC coil would be an example of this, but there should be other ways to do it), this allows the circuit to "relax" regularly every millisecond/microsecond/picosecond (relative to CPU speed / transistor switching speed).

Net result is that circuit should not get hot, ever...

Rule of thumb (for future CPU engineers): If you're storing bits in a circuit that gets, or can get hot over time -- you're doing it wrong... (even though humanity's CPU engineering history up until this point in time is that every CPU created thus far -- stores and manipulates bits in circuits that generate heat!) <g>