One question- do these vulnerabilities , including spectre and meltdown only help in stealing information or can they also hijack your computer to do arbitrary things?
[deleted]
More Intel speculative execution vulnerabilities
151–160 of 262 posts
Re: More Intel speculative execution vulnerabilities
#152Earlier quoted context omitted.
One of the problems with Intel culture - especially under BK was that the philosophy was "Focus on our key goals to the exclusion of everything else". It was meant to keep focus and ensure we moved quickly. The problem with that is it meant we were entirely unresponsive. It doesn't matter if something important has come up because you've already agreed what the priority is, you've already committed to what you're goi…
Dumb question: Can you clarify what ZBB'd means in this context? I've never seen it before. There's a wiki page [0] with various meanings for the abbreviation, but nothing seemed to fit. Maybe Zero-based budgeting? [0] https://en.m.wikipedia.org/wiki/ZBB
Zero-based budgeting. It effectively means that a project is no longer getting funded or staffed and is therefore dead.
Re: More Intel speculative execution vulnerabilities
#153> On July 3, 2019, we finally learned that, to our surprise, the Intel PSIRT team had missed the PoCs from our Sep 29 submission, despite having awarded a bounty for it, explaining why Intel had failed to address - or even publicly acknowledge - many RIDL-class vulnerabilities on May 14, 2019. What does this usage of the word 'missed' mean in this context? That they lost it / failed to deliver the PoC to the relevant…
From the way the phrase is turned, I believe they released a fix that covered all previously known PoCs but not those from that submission.
Generally speaking, that really illustrate the dumb way Intel is going about it, fixing on a PoC basis rather than going after the strong underlying problem. It basically screams "there will always be issues, the question is can you find them !".
Re: More Intel speculative execution vulnerabilities
#154Earlier quoted context omitted.
Not very likely: the attacker is outside the emulated vulnerability-free sandbox, and the state of the emulator is exposed like the state of any other program. Accessing the emulator's memory means accessing the emulated program's memory, it's just slightly obfuscated.
How is the attacker outside, assuming it's a process running on the emulator (I.e. the attacker surface here in the emulator example would be only the NES game, so he has to work with NES cpu opcodes, NES memory locations etc)?
Spectre was exploitable from javascript, so all of your same questions apply there. The answer is that a virtual env like that doesn't really stop an attacker, they just have to sort of meta program what they want the emulator to do rather than writing native machine code themselves. A little harder, but still doable.
Re: More Intel speculative execution vulnerabilities
#155So Intel failed to mitigate the vulnerability when it was first reported. Then they extended the embargo from May until November. And they still didn't fix it. What's going on with Intel? Like they're going all in with lying in benchmarks against AMD and straight up forgetting what has been reported as security issues.
> going all in with lying in benchmarks against AMD I'm assuming this is referencing the "intentionally misleading benchmarks" piece in servethehome. It's worth reading the follow up, in which the author discovers their biggest complaint (older version doesn't have avx2 enabled by default on zen2) was not an issue because Intel manually enabled avx2. https://www.servethehome.com/update-to-the-intel-xeon-platin...
They request all benchmark done with SMT off, they insist on doing their bench without the security fixes for Spectres/Meltdown applied, they use dubious TDP counting, ...
AMD has its fair share of issue in their own self published benchmarks, but at least when third party publish they're not forced to cripple other companies' chips.
Re: More Intel speculative execution vulnerabilities
#156Earlier quoted context omitted.
> It feels like the death of a company is inevitable. Which, from a higher perspective, is good. As it breaks down monopolies and give way to more innovative new companies.
It's good when we allow them to fail gracefully. I would hate to see what unscrupulous stuff a failing Google could do with all our info being held hostage.
No need to wait or wonder. Google Equifax.
Re: More Intel speculative execution vulnerabilities
#157Earlier quoted context omitted.
The problem for most of these is not speculative, it's not doing proper acl during speculation. Just because the cpu is speculating doesn't mean it shouldn't check if you are allowed to access this or that, but that's what Intel did, and they only did the security check at the end before giving back the result, except at this point its too late you've already accessed it. Other manufacturers AMD included didn't get a…
I wonder what the performance costs of those ACL checks are.
A single one might not be that big, but they add up (if there are several suchs checks to do in your speculated branch, instead of doing them when they appear during speculation intel chips pooled them up all at the end), and they disappear if the speculation was wrong (speculated the wrong branch ? Didn't lose any time on permission check).
They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations.
Re: More Intel speculative execution vulnerabilities
#158Earlier quoted context omitted.
Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.
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
Re: More Intel speculative execution vulnerabilities
#159Earlier quoted context omitted.
AMD was always a worthy target because they sold a lot of cost-effective mid and low range CPUs to Dell and friends. They have been absent from the peak performance market for a while but that's a small fraction of computers. After all, AMD didn't go out of business, and they had to be selling a lot of CPUs.
But isn't that not where the worry is? Isn't it cloud computing and server spaces where the real damage can be done here?
No, these vulnerabilities potentially let userspace code escalate privileges, which could lead to ransomware or credential exfiltration. Stealing bank account passwords clearly does damage, and various governments have paid ransoms on the order of $100,000 to recover encrypted files.
I’d argue that side-channel attacks are less of a problem in the server space because servers generally don’t download untrusted code from the internet and execute that code blindly (assuming you aren’t running other peoples’ VMs).
Re: More Intel speculative execution vulnerabilities
#160Earlier quoted context omitted.
From what we've seen so far B550 is pretty much just x470 (no PCIE4). And B450, B350 boards will do fine running a 3600. I don't really see a point waiting for B550.
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.