Ok this has been bugging me for a while. How does speculative execution roll back side effect like write to disk or send a packet on the network, when the speculation is wrong. At a guess there are safe instructions that can be run when doing branch prediction?
More Intel speculative execution vulnerabilities
91–100 of 262 posts
Re: More Intel speculative execution vulnerabilities
#92Earlier quoted context omitted.
The cynic in me thinks a good capitalist would try to sell the discovery to the highest bidder. In this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short on Intel stock. I imagine the payoff would be in the millions of dollars in both cases, and I doubt either scenario is even illegal.
> a good capitalist would try to sell the discovery to the highest bidder. Not all security researchers are doing it for the money, 0day markets always exist. Malicious people who wish to use the vulnerability for profit wouldn't disclose the vulnerability to begin with. So it's not a new problem. > this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder wou…
If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading.
Here's an example of Gotham City Research trying this approach and failing: https://www.thedrum.com/news/2017/09/21/criteo-counters-frau...
(Not a lawyer)
Re: More Intel speculative execution vulnerabilities
#93Ok this has been bugging me for a while. How does speculative execution roll back side effect like write to disk or send a packet on the network, when the speculation is wrong. At a guess there are safe instructions that can be run when doing branch prediction?
I/O takes seven eternities in microcode-ville. It doesn't hurt too much to wait for the speculation to be resolved before changing state visible outside the microarchitecture of the CPU.
Re: More Intel speculative execution vulnerabilities
#94Ok this has been bugging me for a while. How does speculative execution roll back side effect like write to disk or send a packet on the network, when the speculation is wrong. At a guess there are safe instructions that can be run when doing branch prediction?
Nothing like that happens. Writes to dram or pcie devices or data bus cannot be rolled back. You have a misunderstanding of what speculative execution entails. The things that get rolled back are writes to general purpose registers.
Re: More Intel speculative execution vulnerabilities
#95Earlier quoted context omitted.
Not saying this happened at IBM, but sometimes correct people can be promoted into correct positions, in which case the company keeps going just fine. However, at some point any company is probably bound to promote wrong people, who will end up promoting/hiring the wrong people under them, eventually completely changing the course of the business. It seems like the death of a company is inevitable.
It also happens that the circumstances that allowed a company to dominate come to an end. It would require heroic measures to move to a new form of dominance. Why should lightning strike again in the same place?
Lightning will strike a place many times if the capital is expended to erect a lightning rod.
Re: More Intel speculative execution vulnerabilities
#96Earlier quoted context omitted.
Thankfully AMD is making serious headway and will continue to take market share from Intel. It will take time but Intel should begin to feel the sting soon.
I'm nearly 20 years in mid to large companies, I've never seen an AMD cpu on a desktop, laptop or server. Its almost like nobody ever gets fired for buying Intel.
So far there was no reason to fire for that.
The only bad period was where AMD Opteron gained a big market share in servers while Intel was doing Pentium 4 Netburst crap.
Re: More Intel speculative execution vulnerabilities
#97Earlier quoted context omitted.
> No I don't give a fuck about the 'risk' this introduces Well, let's hope you're not powned because of this and get dragged into giving some fucks, for a 5-10% of performance hit you wouldn't notice anyway...
Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ? And they are not particularly unique. Do you understand my risk and load requirements better than I do ? Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ? But thanks for y…
>Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ?
You'd be surprised what people would do. Could be just out of some spite ("fuck Intel"). Could not even include any measurable workloads ("I want my machine to go ultra fast").
>Do you understand my risk and load requirements better than I do ?
For you particularly probably not, but you'd be surprised how many times a third party can "understand the risk and load requirements" of someone else (even a business) better than they do.
E.g. the "No, you don't need a Hadoop cluster for doing "ML" on a 1GB file", phenomenon.
>Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ?
Only briefly, cause the tone of the comment made it sound more of a knee jerk reaction ("No I don't give a fuck about the 'risk' this introduces", "until everything is swapped to AMD") doesn't sound like the fruits of rational analysis...
Re: More Intel speculative execution vulnerabilities
#98Another nail in the casket lake. Is the solution just to throw everything out and start again? Do we just abandon speculative execution?
Or we abandon sharing the same hardware for trusted and untrusted code. (Yes, that includes things like whitelisting JS.)
Re: More Intel speculative execution vulnerabilities
#99Earlier quoted context omitted.
> So 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. The assumption being that they could in the time given, but are sitting on their hands?
No. This timeline shows incompetence, not sitting on their hands: https://mdsattacks.com/#ng-full-story
Incompetence as in "they're incompetent engineers", and if so, compared to what baseline?
Or incompetence in as "they weren't capable of doing it"?
The latter is very probable. The former could underestimate the difficulty of such fixes...
Re: More Intel speculative execution vulnerabilities
#100Is it possible to apply the mitigations on an per-application level in Windows? IMHO it'd be pretty useful to be able have them on by default, but disable them for specific applications where you care about maximum performance and know that you won't be running untrusted code.
Surely if you emulate a processor without speculative execution with good fidelity (Such as a good NES emulator) then the program running ON that emulator can't deduce anything from speculative execution? Is the answer (for home users ) to just sandbox some processes under an emulator layer? I'd be happy to just sandbox some sensitive processes like my browser even if it took a huge performance hit, so long as some o…
I suppose you could run your trusted applications in the top-most Windows instance without mitigations, and run untrusted applications in a virtualized Windows instance with mitigations enabled. Wouldn't be pretty or very practical, but I suppose it might work?