Reading privileged memory with a side-channel • Hacker News Board

Re: Reading privileged memory with a side-channel

#281

Post by Unklejoe » Thu, Jan 04, 2018, 1:09 AM UTC

Just an idea that I had:

If these exploits seem rely on taking precise timing measurements (on the order of nanoseconds), could we eliminate or restrict this functionality in user space?

The Spectre exploit uses the RDTSC instruction, and this can apparently be restricted to privilege level 0 by setting the TSD flag in CR4.

I know it would kind of suck, but it might be better than nothing.

I would think that most typical user applications wouldn't require that accurate of a time measurement. If they do, then maybe they can be white listed?

Re: Reading privileged memory with a side-channel

#282

Post by caf » Thu, Jan 04, 2018, 1:10 AM UTC

partiallypro wrote: post #16

So, is AMD effected or not? This seems fairly important. The Google blog post sort of goes against itself in this regard. AMD itself has said: "The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time." So either AMD is lying or Goog…

AMD is saying that:

  !(susceptible_v1 && susceptible_v2 && susceptible_v3)

They are not saying that:

  !susceptible_v1 && !susceptible_v2 && !susceptible_v3

(the latter would be rendered in English as: "AMD is not susceptible to any of the the three variants")

Re: Reading privileged memory with a side-channel

#283

Post by jchw » Thu, Jan 04, 2018, 1:10 AM UTC

dannyw wrote: post #237

kibwen wrote: post #212

Earlier quoted context omitted.

> Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Here's the synchronized announcement from Chrome/Chromium: https://sites.google.com/a/chromium.org/dev/Home/chromium-se... "Chrome's JavaScript engine, V8, will include mitigations starting with Chrome 64, which will be released on or around January 23rd 2018. Future Chrome releases will include additional…

The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.

> ...severely round performance.now().

This sucks, and is a side-effect that I didn't even think about. I guess it's probably pretty effective, but it will make benchmarking a lot harder, since you'll probably now have to do a lot more runs.

Re: Reading privileged memory with a side-channel

#284

Post by dmm » Thu, Jan 04, 2018, 1:12 AM UTC

deckard1 wrote: post #276

jwilk wrote: post #239

Earlier quoted context omitted.

And if you're a web developer, now it the good moment to make sure your site works correctly when JS is disabled.

We'll have to dig a time machine out and go back to 1998 then. I'm being a facetious ass. But you know I'm not wrong, either.

You are wrong. Install the NoScript extension and you can see your site without js. NoScript also allows you to selectively enable js per site on a temporary or permanent basis. This is the default way that I and many other people browse the web.

https://noscript.net/

Re: Reading privileged memory with a side-channel

#285

Post by theptip » Thu, Jan 04, 2018, 1:14 AM UTC

drdrey wrote: post #257

theptip wrote: post #194

Earlier quoted context omitted.

I think this means we should consider all browser processes to be completely insecure, until mitigations are applied (e.g. Chrome's Site Isolation: https://www.chromium.org/Home/chromium-security/ssca ). Looks like any session token/state could be exfiltrated from your Gmail tab to a malicious JS app running in-process, for example. Am I overreacting here?

Doesn't each tab run in a separate process?

That's true to first approximation in Chrome, but apparently not always.

This recent article contains a bit more detail on Site Isolation: https://arstechnica.com/gadgets/2017/12/chrome-63-offers-eve...

> Chrome's default model is, approximately, to use one process per tab. This more or less ensures that unrelated sites are kept in separate processes, but there are nuances to this set-up. Pages share a process if they are related through, for example, one opening another with JavaScript or iframes embedding (wherein one page is included as content within another page). Over the course of a single browsing session, one tab may be used to visit multiple different domains; they'll all potentially be opened within a single process. On top of this, if there are already too many Chrome processes running, Chrome will start opening new pages within existing processes, resulting in even unrelated pages sharing a process.

Which suggests there are a number of cases where multiple tabs could share a process.

Re: Reading privileged memory with a side-channel

#286

Post by olliej » Thu, Jan 04, 2018, 1:17 AM UTC

_delirium wrote: post #101

hrpnk wrote: post #86

Earlier quoted context omitted.

Both domains were registered on 2017-12-22. Given the planned disclosure on 9th January that Google mentions and MS and others coding patches silently [1], do the early reports [2] of kernel patches, does this mean that due to coding in the open the whole disclosure procedure has been vastly accelerated? I wonder how the timing relates to New Year and many companies having holidays in CW1. [1] https://lists.freebsd.o…

Accelerated, but not vastly. Google's post says "We reported this issue to Intel, AMD and ARM on 2017-06-01", so the embargo still ended up holding for 7 months, even with it ending a week early. The domain registration dates of 2017-12-22 seem to be just when Google started to prepare for releasing the publicity materials, not when the vulnerability was discovered.

The problem isn't "it's not bought forward by that much relatively" in as much as you have an agreed timeline to have coordinated patches (e.g so one org doesn't push a fix before other orgs have). So if you have a bunch of orgs set up to do a release on day X, and then publish on X-[whatever] then you are effectively zero-daying.

Is it super important in this case? shrug.

But imagine for the sake of argument there was some undocumented cpu behaviour "if instruction x,y,z are executed in that order with these constants then catch fire", then having anyone pre-empt the agreed update time could be bad.

Re: Reading privileged memory with a side-channel

#287

Post by mtgx » Thu, Jan 04, 2018, 1:17 AM UTC

mrmondo wrote: post #13

"AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected." - http://www.zdnet.com/article/security-flaws-affect-every-int... * Edit: From https://meltdownattack.com/ Which systems are affected by Mel…

"Intel suffers a Meltdown" should be an apt headline for tomorrow's headlines.

Re: Reading privileged memory with a side-channel

#288

Post by caf » Thu, Jan 04, 2018, 1:18 AM UTC

webaholic wrote: post #235

static_noise wrote: post #121

Earlier quoted context omitted.

Only if your speculative reads do cause irreversible side-effects on those caches. You could implement them in a way that doesn't modify the caches... but that would be complicated and probably use more power and have lower performance.

One of the main reasons for speculative execution is to fetch data into the caches ahead of them being needed. If you don't modify the cache, then you throw that away. May be one way would be to use a smaller, separate cache for speculative execution and then copy that value to the regular cache once speculation is confirmed? This would add a one cycle latency for cache-to-cache transfer but there might be better way…

This might actually improve performance because it would prevent actually-hot data being evicted from the cache in favour of cold data that was loaded in a not-taken speculated branch.

Re: Reading privileged memory with a side-channel

#289

Post by aidenn0 » Thu, Jan 04, 2018, 1:18 AM UTC

dannyw wrote: post #237

kibwen wrote: post #212

Earlier quoted context omitted.

> Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Here's the synchronized announcement from Chrome/Chromium: https://sites.google.com/a/chromium.org/dev/Home/chromium-se... "Chrome's JavaScript engine, V8, will include mitigations starting with Chrome 64, which will be released on or around January 23rd 2018. Future Chrome releases will include additional…

The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.

That can't be right because they already round performance.now() so the Spectre attack didn't use it (it instead used a webworker with a tight-loop incrementing a counter)

Re: Reading privileged memory with a side-channel

#290

Post by gmueckl » Thu, Jan 04, 2018, 1:19 AM UTC

static_noise wrote: post #121

cesarb wrote: post #102

Earlier quoted context omitted.

You can't unwind completely. Once the cache is full, to load something on the cache, it has to evict something else. You might be able to evict what you just loaded, but you can't undo the earlier eviction.

Only if your speculative reads do cause irreversible side-effects on those caches. You could implement them in a way that doesn't modify the caches... but that would be complicated and probably use more power and have lower performance.

There does not need to be a performance hit, but cache complexity must rise: speculative execution must use a separate cache for any data that was fetched speculatively. Only when that branch is truly accepted must that data enter the "real" cache. As long as speculative execution does not go on for too long, these secondary caches can stay really tiny (a handful of cache lines maybe).