The Market Ticker
Rss Icon RSS available
You are not signed on; if you are a visitor please register for a free account!
Comments on It's Operating As Designed (ROFL!)
User: Not logged on
Top Forum Top Login FAQ Register Clear Cookie
Showing Page 2 of 2  First12Last
User Info It's Operating As Designed (ROFL!) in forum [Market-Ticker]
Spazznout
Posts: 1759
Incept: 2009-04-15

Columbus, Ohio
Report This As A Bad Post Add To Your Ignored User List
What are the consequences for crypto currencies that have exchanges and block chains running through these chips???

What about banks and the major pos transaction intermediaries visa master card and Amex??????





----------
"In a land without Rule of Law even a sane man who desecrates the state must be made to look crazy. "
Rubicon Jan. 9, 2011 blog post.
"Those who make peaceful revolution impossible, make violent revolution inevitable."
Tickerguy
Posts: 151187
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
smiley

followed by...

smiley

----------
Winding it down.
Dagge
Posts: 62
Incept: 2008-05-16

Tilton, NH
Report This As A Bad Post Add To Your Ignored User List
The problem isn't even returning the CPU to the state it would be in as if the speculative branch hadn't been speculated on (including caches). One thing I haven't seen mentioned is doing a speculative read to a device that changes state based on a read. This could be a very easy, untraceable, DOS vector.

Someone ought to go through your usual Xeon hardware and see if such devices are common, anything with a FIFO or clearing of a bit by a read is a major problem. This could end up an instant death sentence for some hardware combinations (or 90%+ slowdown if the device driver needs to page it's memory on every access).
Kroyl
Posts: 27
Incept: 2015-11-12

Report This As A Bad Post Add To Your Ignored User List
Quote:
Since the CPU doesn't enforce separation of userspace data, then the ability to read userspace data via other means does not seem to be a CPU bug per se. It is a JIT bug, where the JIT is not employing adequate protections.


It _is_ a CPU "bug" (because data leaks that can be formally proved impossible by static analysis become possible in reality).
OTOH, it is unreasonable to expect a modern CPU to _not_ leak any internal state through timing side-channels in every case (especially if you consider SMT/Hyperthreading - where a single set of physical resources simultaneously executes several unrelated threads).
So, it is _also_ a JIT/sandbox bug - the sandbox now has to _know_ about the CPU implementation details in order to apply effective mitigation strategies.

The problem is that the modern CPU is a leaky abstraction - in this particular case, the abstraction "leaks" through timing differences.
There are two worlds:
1) the observable set of registers/memory - which behaves exactly according to CPU specification
2) the hidden state (caches/shadow registers) - which retains sensitive information and may be indirectly observed through timing differences.
Avoiding these timing differences is prohibitively expensive (the *whole point* of caching is to reduce the latencies if possible).

Even when a sandbox/JIT implementation is theoretically correct, and can be formally proven to not leak any sensitive data to untrusted code, it becomes exploitable in practice *because* of these timing differences.
And there are probably dozens of various subtle microarchitecture-specific timing dependencies requiring careful mitigation (such as memory barriers and cache flushes) in the sandbox host process.

Thus, both Firefox and Chrome, for now, have reduced timer precision and disabled a feature (SharedArrayBuffer) that can be used to implement a high-precision timer in attack code.

https://blog.mozilla.org/security/2018/0....
https://www.chromium.org/Home/chromium-s....

These exploits do not rely on cross-privilege-level speculation - so the mitigations are required for practically all CPUs (including ARM and AMD).
Kroyl
Posts: 27
Incept: 2015-11-12

Report This As A Bad Post Add To Your Ignored User List
Quote:
One thing I haven't seen mentioned is doing a speculative read to a device that changes state based on a read. This could be a very easy, untraceable, DOS vector.


This is very unlikely.
Such memory is normally marked uncacheable in the corresponding MTRR registers - and CPU access to it becomes ineligible for speculative execution.

If speculative execution was possible for hardware-mapped memory, it would cause major problems even in absence of active attacks.
Dagge
Posts: 62
Incept: 2008-05-16

Tilton, NH
Report This As A Bad Post Add To Your Ignored User List
I also would've thought changing protection levels/rings would render a memory read ineligible for speculative execution....

Tickerguy
Posts: 151187
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
Quote:
I also would've thought changing protection levels/rings would render a memory read ineligible for speculative execution....

Oh, you mean that the CPU should check to see if it would page fault BEFORE it plays speculative execution? Well, yes, it should... but apparently Intel doesn't.

----------
Winding it down.
Notrehtad
Posts: 1
Incept: 2018-01-04

Report This As A Bad Post Add To Your Ignored User List
So... I guess these processor people just need to check their privilege...
Login Register Top Blog Top Blog Topics FAQ
Showing Page 2 of 2  First12Last