New x86 micro-op vulnerability breaks all known Spectre defenses • Hacker News Board

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

#121

Post by fnord77 » Sat, May 01, 2021, 12:01 PM UTC

elihu wrote: post #76

baybal2 wrote: post #30

Earlier quoted context omitted.

You are completely correct. 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.

> The safe execution of any untrusted Turing complete code is a pipe dream. 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…

turing architecture - code and data are handled the same way.

harvard architecture - code and data are separate things

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

#122

Post by jka » Sat, May 01, 2021, 12:17 PM UTC

indigochill wrote: post #95

akersten wrote: post #25

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…

> We're going to wind up undoing the last 20 years of performance gains in the name of 'security', and it scares me. 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…

Good thinking, although I'd be a little wary about making a clear distinction between those two classes of device.

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)

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

#123

Post by daneel_w » Sat, May 01, 2021, 12:23 PM UTC

mort96 wrote: post #105

Woodi wrote: post #85

Simplest way around all of this is back to one-core MULTI-SOCKET systems for "civilian" computers like x86 is.

You're gonna put 10-16 sockets on one motherboard?

Blade servers seem like an efficient solution in terms of area and volume used, and there's probably a lot more to explore in the concept.

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

#124

Post by dexen » Sat, May 01, 2021, 12:23 PM UTC

miloignis wrote: post #83

addaon wrote: post #54

Earlier quoted context omitted.

Timing attacks are only a subset of side channel attacks, though. One can also imagine thermal attacks -- the amount of power you consume leaks information about what you're doing. And if I share a processor with you, there's various ways I can imagine estimating your power usage. On a processor that has dynamic clocking, the clock speed I'm running at is an indicator of the operations you're doing. Even without dyna…

Determining what clockspeed you're running seems like it would also require access to timing information though, right? RAM errors is an interesting idea for sure, but I think that can and should be shored up at the RAM level. I think a strong sandbox, WebAssembly and the like, should be pretty reasonable to run untrusted.

A 2013 paper[1] demonstrating exactly that: side channel detecting thermals that's measured without measuring on-CPU timing.

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

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

#125

Post by kllrnohj » Sat, May 01, 2021, 12:32 PM UTC

1e-9 wrote: post #22

dataflow wrote: post #21

Question: How relevant are these for the average person? I know these matter for things like shared hosting, but I've yet to hear of an actual exploit in the wild that ordinary people have been attacked by, even with Spectre defenses turned off. Should normal people be worried about this?

Yes. It could undermine your browser if you allow a malicious site to run JavaScript.

Not really. So far these mostly haven't been able to cross process boundaries, and most browsers have tripled-down on process-sandboxing by this point (iframe sandboxing was the last major push here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if... )

So process-based sandboxing will continue to be the defense here, and process switching will just get a little bit slower as increasingly more caches are flushed (toss the uOp cache into that list now). For basically all consumer usages this will be perfectly fine. On the other hand, things like Cloudflare's Workers are looking a lot more suspect.

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

#126

Post by jimktrains2 » Sat, May 01, 2021, 12:46 PM UTC

MaxBarraclough wrote: post #112

Salgat wrote: post #82

Earlier quoted context omitted.

Will this even be an issue when we have CPUs with hundreds/thousands of cores that can just sandbox processes to their own set of cores/cache with exclusive unshared memory?

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…

And "lower capacity" isn't even that low any more, just in comparison with top-of-the line. Think a raspberry pi or basically any cellphone's main logic board. My motorola g7, that I got for something like $150 new, has Snapdragon 632 processor with 1.8 GHz octa-core CPU and Adreno 506 GPU, 4 GB of ram, and 64 GB internal storage. A pi4, for under $100 has a Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz and up to 8GB or ram. Those specs far outclass most budget VMs and are more than adequate for the vast majority of workloads. All that either is missing is a proper storage port (i.e. not an sd card but something like sata or m3), but otherwise how many raspberry pis could fit in a 1u enclosure? Even being generous and giving half of the volume to disks, dual power, and cooling it's still quite a few.

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

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

#127

Post by the8472 » Sat, May 01, 2021, 12:48 PM UTC

tachyonbeam wrote: post #65

londons_explore wrote: post #3

The solution will be "do not share the micro-op cache between different address spaces". Which for old hardware will translate to "flush the micro op cache every time the address space changes". I would guess that can be done with a microcode update and that the performance hit wont be too massive.

The micro-op cache is very small, on the order of ~1.5K uops AFAIK. It can also be repopulated quite fast. So yes, the performance hit should be quite small. You should presumably also be able to reduce the performance hit if you reduce the frequency of context switches, which should get easier the more cores you have, if I'm not mistaken. That is, the OS can have its own dedicated core, and some programs can be more…

> You should presumably also be able to reduce the performance hit if you reduce the frequency of context switches, which should get easier the more cores you have, if I'm not mistaken.

Context switches don't happen that often due to preemption unless your CPU is oversubscribed. Most context switches are due to syscalls, especially the ones used to wait for contended locks. Reducing those takes a lot more optimization work.

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

#128

Post by api » Sat, May 01, 2021, 12:51 PM UTC

akersten wrote: post #25

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…

It’s also possible that we strip off a ton of complexity and then find new performance directions that are better.

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.

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

#129

Post by zokula » Sat, May 01, 2021, 1:00 PM UTC

smasher164 wrote: post #75

Maybe EPIC [1] architectures need a revival. Rely on compilers to take advantage of explicit instruction-level parallelism, and keep the CPU dumb. [1] https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...

> Rely on compilers to take advantage of explicit instruction-level parallelism, and keep the CPU dumb.

This very much is never going to be feasible for consumer and general purpose computing.

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

#130

Post by grishka » Sat, May 01, 2021, 1:00 PM UTC

tyingq wrote: post #10

spacemanmatt wrote: post #6

Is ARM so much better? I can migrate my AWS hosts.

Separate micro-op cache per core, and no hyperthreading, so ARM would seem better equipped to defend against this.

So ARM CPUs do have microcode after all?