Are you referring to retpolines? Browsers and JS are *extremely* virtual call heavy. Perf impact must be carefully considered.
-
-
Replying to @pcwalton @pwnallthethings and
I haven’t measured, but my guess is that nobody can realistically deploy retpolines for perf reasons. Would be happy to be proven wrong.
1 reply 0 retweets 0 likes -
Replying to @pcwalton @pwnallthethings and
@chandlerc1024 gave the performance impact of a not dissimilar c++ application when posting the retpoline work. Devirtualization and pgo/lto helps a lot though.3 replies 0 retweets 1 like -
Plus, you only need to retpoline the executable code running within the address space with the victim data and attacker untrusted code. Still, I agree with
@fugueish here - best long term strategy is isolation. For short term, v2 may not be the most urgent...2 replies 0 retweets 1 like -
Replying to @chandlerc1024 @echristo and
Are you all sure that process isolation is a foolproof solution? Different address spaces on same core share a cache…
1 reply 0 retweets 0 likes -
Replying to @pcwalton @chandlerc1024 and
See “same-CPU cross process” on https://github.com/marcan/speculation-bugs/blob/master/README.md … —
@marcan42 seems to agree that cross process is potentially vulnerable too…1 reply 0 retweets 1 like -
Replying to @pcwalton @chandlerc1024 and
Yeah, the only complete solutions are full IBRS/IBPB (enabled in both the kernel and userspace) or using retpolines everywhere, AFAICT.
1 reply 0 retweets 1 like -
and as I suppose you know, those are only complete solutions for variant 2, don’t help with 1
1 reply 0 retweets 0 likes
Of course. Insert rant about calling two different vulns by the same name. As I mentioned on the doc and Reddit, I don't think there's a fix for variant 1 other than making speculation barriers part of the CS curriculum.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.