231–240 of 262 posts
Earlier quoted context omitted.
Not every computer runs a web browser. Of the hundreds of high performance cores I have, only a couple run a web browser. ... thought increasingly more of them are non-intel.
What about a network stack? Are they running one of those exposed to adversaries? http://www.misc0110.net/web/files/netspectre.pdf
Earlier quoted context omitted.
Wow, that is impressive. Yes in theory you could do that, but to actually exploit in practice I would have guessed couldn't be done.
Don't get too excited. From the paper: "In the Google cloud, we leak around 3 bits per hour from another virtual machine." This is, of course, under ideal conditions.
Still not very useful for an attacker.
But still fascinating and impressive they could do it at all.
Earlier quoted context omitted.
There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes. It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't…
What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0] Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution. Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably…
Earlier quoted context omitted.
I just read your username. Well played.
It's not a joke. Only an asshole tells other people they should be doing things a certain way with absolutely no understanding of their use cases, needs, or constraints. And I really do run my desktops with mitigations disabled. Sky hasn't fallen, computer performs better. If you're the kind of security-uber-alles idiot who thinks this is crazy, then you're using OpenBSD for your desktop right?
Earlier quoted context omitted.
I see your point, but I think that is because of a lack of commitment to higher integration functional blocks. A lot of work done on a FPGA is very regular. I suppose LUTs could be the best way to do create the glue logic that basically amounts to signal routing and synchronization, but it seems unlikely.
I'm not going to be surprised if FPGAs of the future start building in on-chip non-blocking CLOS-networks to more efficiently route messages across the chip. https://en.wikipedia.org/wiki/Clos_network Dedicated-hardware that serves a purpose. Sure, you can build a CLOS-network out of LUTs, but it'd be more efficient if you made dedicated hardware for it instead.
> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, l…
Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything, just two or three additional unpatched PoCs with full source code would be enough. However, unlike buffer overflow exploits, most researches on CPUs are conducted within academic institutions, doing this certainly breaches the code of conduct. Also, CPUs are the most cr…
At the risk of sounding pedantic, that's not 'full disclosure', that's 'responsible disclosure' - https://en.wikipedia.org/wiki/Responsible_disclosure
Earlier quoted context omitted.
> They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations. Given AMD's Zen 2 has comparable IPC to Intel at this point without doing the ACL check late it's not evident that the difference in when the ACL is done was a key efficiency gain.
They get that IPC on a better process. Shorter gate delays let you pack more into each cycle. IPC can't be divorced from process when comparing architectures.
Earlier quoted context omitted.
The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers. But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand. You just make these attacks more likely; I'm not going to be impacted…
>The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. Oh, so it just takes more time, so you have knowledge of an exploit? Fine, show me any PoC or similar bypassing the lower accuracy and site isolation. You are such a big part of the problem with how this whole class of exploits have been handled. No technical knowledge, just spewing stuff like "You're th…
another 0-4% performance hit for skylake
The really damning part is that it applies even for processors that are supposedly fixed in silicon because Intel dropped the ball by playing wack-a-mole with proof of concept exploits instead of thoroughly building their chips with security in mind. If the history of Microsoft and Windows security is any indication, it'll take Intel many many years to turn that ship around. There's a question of whether AMD has been…
AMD's Bulldozer debacle may be a better example, because in some ways it's a better example than Windows.
By that, I mean two things.
1) Silicon typically has a pretty long up-front design phase. Meaning there's probably at least 2 upcoming generations in development at any given time.
2) Intel's marketing is somewhat coy about 'architecture' changes, but the sources I found (admittedly just an SO post and Wikipedia) indicate that the number of pipeline stages in the Core series has not changed much over the last few years. IOW it's probably not a full architecture revamp in their 3-step cycle.
P6 as an Arch lasted around 15 years, when you think about it (including the original 'Core' i.e. Core 2 Duo/Solo here, as while heavily optimized and revamped, it was still P6). K7/K8 lasted about the same longer (15-ish). Netburst was a bit of an outlier, only lasting around 7 years. Same for Bulldozer.
Big assumption here, but based on the pattern I'd assume that Intel originally wasn't even considering a full revamp (or, depending on how they do their iterations, it wouldn't be fully revamped) to be ready until around 2023.
Because of the time involved (back to the first point,) I doubt they would be able to have the problem mitigated in silicon until 2021 at the earliest. (As a bonus, they'd probably want/have to qualify it extra well, lest they accidentally introduce a whole new class of vulnerabilities.)
Earlier quoted context omitted.
It's mostly just that I'm afraid I'll order a board that isn't on the latest bios, which will be a headache. And an excuse to postpone.
Some MSI motherboards (and maybe others?) have a "Flashback" feature to flash BIOS from a USB storage device without needing a CPU.