Are you saying this couldn't happen on whitelisted CPUs? As a hardware engineer, I don't see how you could expect that. You couldn't possibly guarantee this without information the vendor won't give you (detailed timing models w/manufacturing variation).
-
-
You can maybe get a vendor to tell you they tested for this, but most likely they'll just lie to you and roll their eyes internally. Even without overclocking, I've seen this kind of thing happen on server chips (which have more rigorous testing done on them than consumer chips)
1 reply 0 retweets 5 likes -
You can't reasonably test for this yourself in any way. Even if you sample 1M chips uniformly across wafers, fabs, etc., a new stepping, could be a simple 1-layer fix, could completely change time and invalidate all of your testing, you'd have to test another 1M sampled uniformly
2 replies 0 retweets 2 likes -
You misunderstand, we check the whitelisted subset of functionality we rely on, of course we can check it works as we expect?
1 reply 0 retweets 0 likes -
You specifically said you're concerned about things like overclocking causing incorrect behavior on branches How exactly do you check that doesn't happen and branches are executed properly on overlocked CPUs?
1 reply 0 retweets 1 like -
We test it. I think you're asking how can I be certain that it will work on every unit of that model ever produced, but obviously the answer is we can't, but we have higher confidence after checking?
1 reply 0 retweets 0 likes -
Since you're whitelisting based on vendor (?), no. Testing one uarch shouldn't give you any more that another uarch works than that a Transmeta chip works. And within one uarch, how exactly are you testing? I suspect the answer is technically yes, but only in a meaningless way.
1 reply 0 retweets 1 like -
It's a compromise, I would prefer a more specific check. Not sure what alternative you're proposing, just start depending on how obscure parts of the spec works under attack without even testing?
1 reply 0 retweets 0 likes -
IMO, this answer sounds like 1. Something must be done 2. This is something 3. We should do this I think almost any competent CPU engineer would tell you that this actually has no meaningful impact. You're pointing out a real problem, but that doesn't mean this helps at all.
2 replies 1 retweet 6 likes -
Well, it must be nice to not have to compromise. I disagree, we can test and get vendor buy-in on supporting novel new security models.
1 reply 0 retweets 0 likes
I've seen the other side of these vendor discussions at hardware vendors and cloud vendors and in both cases I've seen management directly lie to customers to get customers to think that their concerns have been addressed. YMMV, of course.
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.