141–150 of 203 posts
Earlier quoted context omitted.
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?
Microcode has been around for half a century at least, much longer than micro-ops.
I expect this to be just like Spectre. The media sizes it as a tool to use fear to drive engagement, vendors partially cripple their hardware to guard against it, and literally nobody ever bothers trying to actually use it against innocent people.
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…
> The problem of Javascript bloat doesn't have a technical solution. It would go away in short order if Google rankings severely penalised it.
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. 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…
> 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…
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…
20 years ago, computer magazines wrote about single-core 10GHz CPUs. Billions of transistors. What we have can barely be described as performance gains more than "add SIMD and more cores, and performance hacks".
Yeah, because they didn't realize how terribly the power consumption / heat output would scale; a 10GHz CPU will just melt itself.
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…
The challenge is more how to make a fast CPU like that.
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…
That helps with multitasking and parallel-friendly workloads, but lots of stuff isn't easy to make multithreaded.
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…
Completely agree about SpecEx. That's a misfeature that needs to die.
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…