Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New x86 micro-op vulnerability breaks all known Spectre defenses

sciencedaily.com

Post reply on HN
Print view View original

151–160 of 203 posts

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

#151

Post by otabdeveloper4 »

mort96 wrote: post #104
otabdeveloper4 wrote: post #81

Earlier quoted context omitted.

The problem of Javascript bloat doesn't have a technical solution. 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", a…

But JavaScript bloat is allowed to stay (by product managers, middle managers, UX designers, etc) because the website is still fast. If the JS bloat actually caused the site to become too slow on fast machines, people with power to change stuff would demand change.

Management can't make these sorts of decisions.

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

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

#152

Post by otabdeveloper4 »

tannhaeuser wrote: post #96
otabdeveloper4 wrote: post #81

Earlier quoted context omitted.

The problem of Javascript bloat doesn't have a technical solution. 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", a…

No reason to insult web developers in general. The simpler explanation is that webapps exist because of an economical problem: that you can make more money (have lower barriers) by either recurring payments for services, or by selling your user's attention, or both.

I do lots of frontend development myself, so I'm a kind of "web developer" as well. And I'm insulting web frameworks, not webapps in general.

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

#154

Post by anoncake »

otabdeveloper4 wrote: post #81
userbinator wrote: post #73

Earlier quoted context omitted.

It sounds like a dream, but going back towards interpreted JS instead of JIT may finally stem the insanity of bloat that JS has evolved in an environment of increasingly fast implementations.

The problem of Javascript bloat doesn't have a technical solution. 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", a…

Once JIT is disabled, webapps are no longer viable. Which means we can start to deprecate features content-based websites don't need, and eventually, JS itself.

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

#156

Post by ben_w »

Wowfunhappy wrote: post #144
Fnoord wrote: post #118

Earlier quoted context omitted.

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

If a nation state wants to hack into my computer, I have absolute confidence they will succeed. They are not a part of my personal threat model.

If they’re targeting me in particular, I agree.

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.

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

#157

Post by gravypod »

ineedasername wrote: post #153

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.

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

#158

Post by ThrowawayR2 »

api wrote: post #128
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 stron…

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

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

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

#159

Post by injinj »

feffe wrote: post #103
hajile wrote: post #55

Earlier quoted context omitted.

The performance claims are true for all the worst reasons. Let's say you can queue up 100 instructions. This yields the following 1 port 100% of the time 2 ports 60% of the time 3 ports 30% of the time 4 ports 10% of the time 5 ports 2% of the time Increasing the buffer to 200 instructions yields the following 2 ports 80% of the time 3 ports 40% of the time 4 ports 15% of the time 5 ports 4% of the time As in that ma…

The memory latency hiding also works with 2-way SMT. I worked on a networking software doing per packet session lookup in large hash tables. SMT with a Sandybridge core in this application gave 40% better performance which is higher than usually mentioned. So for memory bound (as in cache misses) applications, SMT is a boon.

I have a graph for this:

https://github.com/raitechnology/raikv/blob/master/graph/mt_...

The CPU in this case is a Threadripper 3970x, 32 cores, 64 SMT.

My experience is this: When the L3 cache is effective, then the memory latency hiding via memory prefetch works well across SMT threads. If the hashtable load requires a chain walk, the SMT latency hiding is less effective because the calculated prefetch location is not the actual hit. I couldn't get prefetching multiple slots as the load increased to be as effective as prefetching a single slot.

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

#160

Post by sitkack »

the-smug-one wrote: post #106
kdma wrote: post #91

Earlier quoted context omitted.

https://googleprojectzero.blogspot.com/2019/04/virtually-unl... one of the many public browser RCE. Or look for the ps5 jailbreaks, the browser is the common denominator for most systems and its leaky as hell given that JS is dynamically typed and everything gets JIT-ed to hell ( https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ ) most exploits I've seen are about tricking webkit into type mismatching + JI…

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

Post reply on HN