That post blames Intel, but it's not just them. NaCl forcibly crashed (and Google refused our trivial fix!!!), random drivers wouldn't work, you had to get a patched Windows installer for multiple releases of Windows (difficult in the days of CD installers), etc.
-
Show this thread
-
Dan Luu Retweeted Dan Luu
The Google Chromium team banning our CPUs is especially ironic in retrospect since they cited security concerns. At the time, we were mostly shipping in-order CPUs, not vulnerable to Metldown/Spectre/etc. and of course Intel is the most vulnerable these.https://twitter.com/danluu/status/779746231287328768 …
Dan Luu added,
5 replies 34 retweets 165 likesShow this thread -
The security of NaCL required accurately predicting controlflow, and confidence it would work in adversarial conditions (e.g. someone trying to induce faults, undocumented opcodes, etc.). I said it seemed prudent to whitelist cpus we had tested, I stand by that.
1 reply 0 retweets 6 likes -
If someone overclocks their cpu, and an attacker does some x87 operation in a tight loop for a few minutes, how confident are you a branches won't be miscalculated? Usually no security consequences for this, so vendors didn't test, It worried me
e.g.https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35923 …3 replies 4 retweets 8 likes -
This wasn't a popular opinion, people worried it would hurt adoption. It probably did, but my job is to worry about security.
2 replies 1 retweet 2 likes -
how did any check to make sure the vendor string was "GenuineIntel" stop the security issues caused by Meltdown and Spectre?
1 reply 0 retweets 1 like -
It didn't, but it likely did prevent trivial shellcode execution on some systems. Does a mitigation have to stop all vulnerabilities to be useful? That would mean there has never been a useful mitigation.
1 reply 1 retweet 1 like -
If the mitigation has shown to fail for several important vulnerabilities, it could be an idea to review if other choices would have been just as effective but without the negative side effects that originated from hardcoded exclusion of vendors. It's a spoofable string anyway!
1 reply 1 retweet 0 likes -
Can you give me an example of a successful mitigation? An attacker cannot spoof the string.
2 replies 0 retweets 0 likes -
I'm wondering if he means it's "spoofable" in the sense that something like a VMM could modify what is passed back. E.g. trap on CPUID and change the value of the registers. There are ways to get drivers loaded without a cert, but that's all I thought of. Just interjecting.
1 reply 0 retweets 0 likes
Sure, but that requires you to have already compromised the system. There's no point trying to interfere with NaCl if you're already a malicious hypervisor, you've already won.
-
-
Oh yeah of course, I'm not arguing just speculating with their original comment since he didn't answer.
1 reply 0 retweets 1 like -
Replying to @daax_rynd @daax_r and
You show that selecting on vendor string was a matter of convenience, not security, as any attack vector would involve building and distributing malicious cpus/devices. If security truly would be the issue, one mitigating measure would be to not run when hyperthreading is enabled
1 reply 0 retweets 0 likes - 2 more replies
New conversation -
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.