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

391–400 of 639 posts

Re: Reading privileged memory with a side-channel

#391

Post by jerrycruncher »

chrisseaton wrote: post #303
dmm wrote: post #284

Earlier quoted context omitted.

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/

I think you’re misunderstanding. The person you’re replying to wasn’t saying you couldn’t disable JavaScript. They are saying the websites they and many in the industry develop won’t work like that and haven’t since the turn of the century. That’s what they were claiming to be not wrong about, and they aren’t. Turning on NoScript shows the problem but doesn’t solve it.

"Turn of the century"? JS was used for little more than swapping images on mouseover and changing/"animating" title bar text back then. The "you will see absolutely nothing or a ream of {{blah}} text" without js enabled really only became prevalent in the last 5-or-so years. Even in the halcyon days of jQuery usage you could get around quite comfortably without js, as js was still being used to augment webpages rather than replace them entirely.

Re: Reading privileged memory with a side-channel

#392

Post by gatmne »

OldSchoolJohnny wrote: post #190
tarruda wrote: post #164

It seems that Richard Stallman is not so paranoid after all: > I am careful in how I use the Internet. > I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git ) that fetches them, much like wget, and then mails them back to me…

RMS remains a rambling nutjob and none of this is really applicable to the issue at hand.

>RMS remains a rambling nutjob and none of this is really applicable to the issue at hand.

Ramblings that this industry has repeatedly proven to be correct, and continue to do so. I'd take his ramblings over a cheap ad hominem any day.

I encourage you to try being more civil the next time you comment on this site.

Re: Reading privileged memory with a side-channel

#393

Post by voidmain »

Unklejoe wrote: post #281

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 typ…

Denying access to timers is kind of practical for browser JavaScript, and should and will happen. But it's not practical for native processes, because shared memory multithreading provides as high precision a timer as anyone could ask for: just increment a counter in a loop in a different thread.

In fact, the practical JavaScript attacks use this method (using SharedArrayBuffer) and the browsers are disabling this (new, little used) feature as a mitigation. But I'm afraid hell will freeze over before mainstream operating systems deny userspace access to clocks, threads, and memory mapped files, which is a lower bound on what it would take to make the attack much harder.

Re: Reading privileged memory with a side-channel

#394

Post by alanfalcon »

mtkd wrote: post #175
noncoml wrote: post #33

Earlier quoted context omitted.

It's a developing story, but from the information we have so far, it does look like Intel involving AMD is a disingenuous since AMD processors are not affected by the most serious of the issues.

It's too early to say which is ultimately the most real-world serious. From the Spectre note (which does affect AMD): In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it. H…

Hardware wallet or bust right now, right? Use a private key that has never touched the internet?

Re: Reading privileged memory with a side-channel

#395

Post by porjo »

diyseguy wrote: post #355
ErikAugust wrote: post #209

Earlier quoted context omitted.

I've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

I thought it was supposed to be exploitable by javascript? If you can get to the machine and run c code, well, that doesn't seem like an exploit?

From the Spectre whitepaper:

> In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.

The whitepaper doesn't contain example JS code however

Re: Reading privileged memory with a side-channel

#396

Post by [deleted] »

diyseguy wrote: post #355
ErikAugust wrote: post #209

Earlier quoted context omitted.

I've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

I thought it was supposed to be exploitable by javascript? If you can get to the machine and run c code, well, that doesn't seem like an exploit?

[deleted]

Re: Reading privileged memory with a side-channel

#397

Post by astrange »

kuschku wrote: post #366
hinkley wrote: post #307

Earlier quoted context omitted.

I wonder what fraction of data inside a kernel is really ‘private’. Obviously we want 100% of the data in the kernel not to be writeable, but if only a small amount shouldn’t be accessible at all then maybe the long term solution is to handle that data in a special way. Something that makes using it slower but doesn’t make every other syscall suffer as much as a consequence. Or maybe the solution is to prioritize mov…

Well the good news is that now microkernels can take over. With KPTI (also known as FUCKWIT), a syscall is now as expensive as a context switch to another userland process. Of course, that means now monolithic kernels run just as slow as microkernels.

Recent Intel CPUs have PCID (TLB tagged by process ID), which makes KPTI not much slower than what we had last week.

Re: Reading privileged memory with a side-channel

#398

Post by guardiangod »

civilitty wrote: post #313
guardiangod wrote: post #214

Earlier quoted context omitted.

From the Spectre paper- We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, aswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones. So in ot…

Spectre and Meltdown are two different exploits. In this case, the paper is talking about Spectre and they did have a POC that worked on all three major processor families (except for deterministic execution engines in microcontrollers and low end CPUs from ARM as well as a few early Atoms from Intel). AMD is saying that Meltdown, which at first glance seems like the most serious one, doesn't effect their processors.

I read the Spectre paper front to back. Where did the paper mention that they have a working PoC for AMD x86 CPUs?

Re: Reading privileged memory with a side-channel

#399

Post by lsh123 »

PuffinBlue wrote: post #100
Cyph0n wrote: post #17

Earlier quoted context omitted.

That's not even close to a thread... You can see all the tweets here (courtesy of @svenluijten): https://twitter.com/i/moments/948681915485351938 .

The linked thread suggests that Spectre doesn't have _any_ mitigation. > The business/economic implications are not clear, since eventually the only way to eradicate the threat posed by Spectre is to swap out hardware. Is this fully accurate, there's no software mitigation available now? From [0], the above may be true: > There is also work to harden software against future exploitation of Spectre, respectively to pa…

There are possible mitigations for cloud providers: 1) pay $x / hour and run on shared machine with possibility of an attack; 2) pay $y / hour (where x Moreover the option 2) already exists for large customers and security sensitive applications (e.g. CIA dedicated cloud built by Amazon).

Re: Reading privileged memory with a side-channel

#400

Post by spenczar5 »

ytpete wrote: post #370
londons_explore wrote: post #333

Earlier quoted context omitted.

I can't really see how it would be fixable even with new hardware. Speculative execution is fundamental to getting decent performance out of a CPU. Without it you should probably divide your performance expectations by 5 at least. Rolling back all state rather than just user visible state in the CPU is neigh on impossible. When you evict something from the cache, you delete it. Undeleting is hard. There are also a lo…

Couldn't you do something like have a separate chunk of "speculative cache" which you only commit to the main cache once the speculatively-executed instructions are retired? Sounds complex, sure - but it seems like that would give you the performance benefits of speculative execution while still being able to roll back (or prevent in the first place) any cache-state side effects when branches were mispredicted. Could…

Possibly - but that's an entirely new processor design. That would take years to get released an adopted.

The scary thing is that you can't fix this in software.

Post reply on HN