Live data from Hacker News

New x86 micro-op vulnerability breaks all known Spectre defenses

sciencedaily.com

171–180 of 203 posts

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#171

undocumented features in Intel and AMD processors Why is this at all a thing? Why would you ever leave something out there like that without documenting its existence?

I'm assuming these are instructions for self tests or verification. If so, removing the instructions after they are manufactured wouldn't be easy. You can do it in microcode at the cost of making all execution slightly slower (if instruction not in [a, b, c, d]) or by physically altering the die to remove those instructions. Either way, it doesn't sound fun. It's probably easier to leave them in.

There's no reason to remove them, that's not what I'm asking. By all means leave them in, but why leave them undocumented? Explain their existence, their parameters & capabilities. If not intended for use, explain that too.

Then when something unexpected like Spectre comes along, the people that have to deal with it can say "Oh yeah, those testing instructions provide another vector of attack that our patch has to account for."

Instead we're in this situation, and I'm pretty sure there's at least a half dozen nations that would have already devoted the resources needed to uncover undocumented instructions like this, meaning ample opportunity to have developed various exploits.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#172

Earlier quoted context omitted.

How would the statically typed WASM open an even wider hole? Assuming you mean that the size of wasm's hole is larger than js, not that their combined holes are larger than either one.

Wasm has more control over time and memory access than JS does. From a capabilities model, it is more secure, but from a threat model due to side channels, Wasm is a more effective tool than JS. This thread discusses SAB (shared array buffer) and Wasm side channels https://github.com/tc39/security/issues/3

But to compensate those tricky features are sandboxed much more rigorously than JS is, e.g. https://developer.chrome.com/blog/enabling-shared-array-buff... - no SAB without site isolation.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#173

Earlier quoted context omitted.

> 20 years ago, computer magazines wrote about single-core 10GHz CPUs Yeah, because they didn't realize how terribly the power consumption / heat output would scale; a 10GHz CPU will just melt itself.

>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.wi…

Addendum:

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!)

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#175

I've been saying this from the start: the well of issues is infinitely deep as soon as you decide that multiple tenants running on the same physical hardware inferring something about another is a vulnerability. I assert, but cannot rigorously prove, that it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating. I don't know…

> is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating

As a counter example, how about the 8086?

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#176
post #150

Earlier quoted context omitted.

I think this idea could be taken further: just build physical machines with lower capacity (RAM, cores), rather than filling data-centers with top-spec hardware then dividing them up with virtualisation. On the face of it at least, this seems like an idea worth taking seriously. With the right form-factor, I imagine it shouldn't even have much of an impact on space efficiency or power efficiency. Perhaps the CPU comp…

Wouldn't that presumably cause energy costs to skyrocket because of all the overhead you get from going from multitenant machines to dedicated ones? Even if the capex is compare I'd imagine it would be hard to get the opex to be competitive

> Wouldn't that presumably cause energy costs to skyrocket because of all the overhead

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.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#177

I've been saying this from the start: the well of issues is infinitely deep as soon as you decide that multiple tenants running on the same physical hardware inferring something about another is a vulnerability. I assert, but cannot rigorously prove, that it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating. I don't know…

I agree completely.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#178
This had to come. The only fix will be to add a BIOS setting for Speculative Access or no speculative access. Gamers all turn it on, with a machine patched, that runs nothing but their game. Everyone else, like browsing the web, off. Look for a encoded binary java script exploit that will own any speculative access system. Its coming too, just like this paper would eventually come.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#179

Earlier quoted context omitted.

> if I have untrusted code running on my CPU, I've already lost 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.

Yeah, JS is the only hairy part. I considered mentioning it, since I know it was going to come up. But luckily, all I've seen so far are basic demos (like leaky.page) that read data from a carefully-crafted array that the page itself populated. I've yet to be convinced that you could realistically exfiltrate meaningful data at any sort of scale with in-browser JS, especially now that more blatant bugs like Meltdown a…

Be afraid. Be very afraid, the hackers are reading this too, as well as the malevolent nation-states hell bent on hacking. I cannot show you a proof of concept right now, but I am betting that within a year, maybe even as quickly as six months. you will see this in the wild.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#180
post #62

Earlier quoted context omitted.

These are timing attacks, if you can guarantee code runs deterministically, and deny access to timing information, you can defeat the attack.

You can't run code deterministically in a multi-tenant system.

does "multi-tennant" also imply "multi-tasking"?

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

Post reply on HN