Re:New x86 micro-op vulnerability breaks all known Spectre d...
by miloignis on Saturday May 01, 2021 @01:41AM
(#27003526)
Determining what clockspeed you're running seems like it would also require access to timing information though, right? RAM errors is an interesting idea for sure, but I think that can and should be shored up at the RAM level. I think a strong sandbox, WebAssembly and the like, should be pretty reasonable to run untrusted.
Re:New x86 micro-op vulnerability breaks all known Spectre d...
by dexen on Saturday May 01, 2021 @08:23AM
(#27005719)
A 2013 paper[1] demonstrating exactly that: side channel detecting thermals that's measured without measuring on-CPU timing.
Instead they measured CPU temperature through frequency drift measured through change of network packet markers. A bit contrived but they made it workable quite reliably.
--
[1] https://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf
Re:New x86 micro-op vulnerability breaks all known Spectre d...
by tylerhou on Saturday May 01, 2021 @02:32AM
(#27003828)
I can still determine timing information by measuring how long it takes to execute a program. The only way to prevent this is to enforce constant-time programs by delaying a response until a specific amount of time (see constant time comparison functions in cryptography). That's not feasible for many applications, especially operations on a latency-sensitive critical path.
Eliminating timing vulnerabilities is necessary to allow potentially-hostile workloads to share hardware, but it is not sufficient.