Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reading privileged memory with a side-channel

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

101–110 of 639 posts

Re: Reading privileged memory with a side-channel

#101

Post by _delirium »

hrpnk wrote: post #86
richadams wrote: post #41

https://spectreattack.com/ Information site with some more information, and links to papers on the two vulnerabilities, called "Meltdown" and "Spectre" (with logos, of course). ( https://meltdownattack.com/ goes to the same site)

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.

Re: Reading privileged memory with a side-channel

#102

Post by cesarb »

static_noise wrote: post #22

So, as I gather, one of the main culprits is that unwinding of speculatively executed commands is done incompletely. That is something that the people doing the unwinding must have noticed and known. Somewhere the decision must have been made to unwind incompletely for some reasons (performance/power/cost/time). As for the difference between AMD and intel. (From other posts here, not this one.) The speculative execut…

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.

Re: Reading privileged memory with a side-channel

#103

Post by static_noise »

chc wrote: post #79
static_noise wrote: post #29

Earlier quoted context omitted.

How much in advance do the intel managers have to register a stock sell?

You mean without getting whomped for insider trading? I don't think they're allowed to do it in advance at all.

As far as I know they HAVE to register a trade in advance. I.E. three months ahead: "I will sell 600 shares on 15th of December if the share price is above 50". This information is public and other people can use this information before the trade actually happens.

Re: Reading privileged memory with a side-channel

#104

Post by cthalupa »

AndyNemmity wrote: post #72
acoye wrote: post #53

Earlier quoted context omitted.

Google security blog says it is. > These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them. https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...

That's unclear, to the point of being factually wrong. Variant 2 and Variant 3 POCs only affect Intel, and those are the ones people are most talking about, and at least to me, the most concerning. Treating them as a group, ignores the very real differences in effect. https://googleprojectzero.blogspot.com/2018/01/reading-privi...

https://meltdownattack.com/meltdown.pdf

>6.4 Limitations on ARM and AMD We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

Seems like the possibility exists that AMD/ARM could be affected, based on the behavior they saw, but they were not able to successfully verify.

Re: Reading privileged memory with a side-channel

#106

Post by rurban »

wslh wrote: post #64

Has Google the best security team in the world? It seems like Google security is in a complete different league. I cannot imagine how this impacts companies handling fiat money or cryptocurrencies in the cloud like Coinbase in AWS.

Did you forget the Technical University of Graz students who came up with rowhammer and KAISER in the first hand?

Re: Reading privileged memory with a side-channel

#108

Post by ateesdalejr »

So, basically CPUs will read instructions inside a branch even if the branch is eventually going to evaluate to false. Does the CPU do this to optimize branch instructions? The results of instructions that are executed ahead of time are stored in a cache. How exactly does this exploit read from the cache? I understand it uses timing somehow but I'm not quite sure exactly how that works. (I mostly do software.)

Re: Reading privileged memory with a side-channel

#109

Post by madez »

trevyn wrote: post #73
adrianpike wrote: post #37

Can someone with a little more experience this low-level let me know if this is as bad as I think it is? Because this looks real bad: > Reading host memory from a KVM guest

"We wrote a JavaScript program that successfully reads data from the address space of the browser process running it." Yeah, it's pretty bad.

A perfect occasion to invite others into my current exercise of using the web without JavaScript.

Re: Reading privileged memory with a side-channel

#110

Post by baybal2 »

static_noise wrote: post #87
srcmap wrote: post #70

Earlier quoted context omitted.

Main/Big impacts are on the cloud computer. For home computer, standard office use, there is no impact at this point, right?

Until someone figures out how to exploit it using JavaScript. The speed this moves it could be any minute now.

Yet another argument against running any native or 1-to-1 bytecode in the browser like WASM
Post reply on HN