Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will
have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels.
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 be running JS anyway.
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 the most stupid thing you can do to disable these mitigations because they're not just theoretical, they're real, they're here and everyone knows about them.
This is like anti-vaxx philosophy. "the risk is low"; well, maybe the risk is low because of herd immunity, it's not feasible to run these attacks as they'll be obvious to those who have the mitigations in place (100% CPU), but if there's a 0.00000001% return then it becomes profitable to exploit, just like mail spam.
Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. Unless you can work without javascript and I doubt you can because the web today is basically unusable without it.
If you have a database which is only accessible internally, you can disable the mitigations, because those things are hit hardest by the mitigations and do not run untrusted code.
But really, your desktop is running untrusted code _a lot_. Please do not do this, not only for your own sake but for everyones sake. Don't make it profitable for malicious agents to run these attacks.
Can you please not post in the flamewar style to HN, regardless of how right you are or feel you are? It degrades the site and provokes worse from others, and we need better than that here. Also, it poisons any good information in your comment.
> It's missing the entire actual implementation of the Spectre attack, which requires analysis of read times to see if you're hitting the processor cache or not.
"analysis of read times" is what the browsers "fixed" to mitigate the attacks (and site isolation later). Again, there has been no working attacks on updated browsers.
Please feel free to link an example of one though, I will gladly admit I'm wrong. You just seem to frankly have no idea how the exploits actually work though (did you actually read the code in the reddit post?), so I suspect that this conversation will be a waste of time.
The browser mitigation’s only work with the kernel mitigation’s. Neither is working well without the other. And yes. I’m very well versed on this topic.
>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 the one who puts their entire digital life on the line", when we there is no indication that anything like that can transpire.
Personal attacks are not ok on HN and we ban accounts that do that, so please don't do that—regardless of how wrong another comment is or you feel it is.
Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement.
This is not misinformation, _you_ are spreading "certainty" of safety surrounding a dangerous idea.
Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
>Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement.
Yeah, which was why SharedArrayBuffer was disabled when spectrev1 was released. It is still disabled in Chrome if site-isolation is disabled and it's still disabled in firefox.
You should really know all this if you are so very well versed in the subject.
>Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
I don't run without migrations. I commented on the original parent comments threat model and that I think it's perfectly logical. And I maintain this, if your threat model is so strict, that you are afraid of speculative execution vulnerabilities hitting you through javascript, you should not run JS at all, as regular js 0days have hit while no actual speculative execution browser exploits have hit.
You have misunderstood how the browser attacks work. They are limited to the memory assigned to the browser process. If site-isolation and the other browser mitigations were somehow bypassed, an ad-network would potentially be able to read some data from other loaded tabs.
You can't use the speculative execution vulnerabilities to just read all system memory using a javascript exploit. Like the exploit that is the topic of this post can't be used in a browser at all, as you are limited to what the JIT executes, you can't just execute TSX instructions in a browser.
You might be thinking of when you have native code execution.
> We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.
They leak in flight data, using a detached spidermonkey engine, patched to make performance.now() return rdtscp at a rate of 1B/s while the victim application is spamming a load string instruction as fast as possible.
This does not allow:
>any ad network can access any and all memory on your desktop
This allows any ad-network to access random bits on the cache line. If the timing mitigation didn't already fix this, it seems impossible to me to get anything useful from it, the precision and bitrate is just too low (which is why the exploit just spams load instructions in a while 1 loop).
>and the RIDL exploits don't require special instructions.
Weird, in the new addendum it says it uses TSX, and in the PoC it uses XBEGIN. Must be a mistake.
As is said in the PoC, it does not bypass index masking and site-isolation. They read data already available to the code they are executing. They did show that the timer resolution mitigation is not 100% effective, which is well known and why it is not the only mitigation.
That's not a speculative execution browser 0day, as it doesn't work in updated browsers and it never has (or I guess it works if you want to leak data you could just console.log). Could you post an actual 0day instead?
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.
>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...
More anecdata: On my workloads, which involves moving large discrete image frames as part of a video inference ML pipeline through a message broker and other processing pipelines, de-mitigating decreased system loads ~25% on average. Some workloads up to 30% depending on inference model. So yes noticeable.
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 ?
>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...
> Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ?
What do you mean by `resource management modeling` in this context? Do you mean `capacity planning` or `system scaling planning` or something else altogether?
