Live data from Hacker News

Reading privileged memory with a side-channel

googleprojectzero.blogspot.com

471–480 of 639 posts

Re: Reading privileged memory with a side-channel

#471
post #389
post #172

Earlier quoted context omitted.

It's a timing attack against the cache. The speculative execution might need to do a read, which means something would need to be evicted from the cache. This makes a subsequent read against that evicted adres slower. This way you can detect things based on speculative execution. I don't know how they go from that to reading memory though.

> I don't know how they go from that to reading memory though. That was the second bit of the example source code: unsigned long index2 = ((value&1)*0x100)+0x200; This creates one of two different addresses, depending upon the value of bit zero of the memory location being attacked. The two different addresses are farther apart than the size of a cache line. > unsigned char value2 = arr2->data[index2]; This actually…

Ah, that makes sense, thanks!

I was thinking of something similar but with a branching operation, but that would get screwed by branch prediction.

Re: Reading privileged memory with a side-channel

#472
post #115

Papers describing each attack: https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf From the spectre paper: >As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). Scary stuff.

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

Work's on Intel® Core™2 Duo Processor T7200. Had to replace __rdtscp(&junk) with __rdtsc(), the Core 2 doesn't have the former.

Re: Reading privileged memory with a side-channel

#473
post #450

Earlier quoted context omitted.

Thank you for this. Would you say this applies to both Spectre and Meltdown, or one and not the other?

This is a general explanation of side channel attacks, as I understand.

yeah, I don't think it is a perfect analogy for Meltdown, I'll try one, someone correct me if I'm misunderstanding Meltdown.

Let's say you want to know if your boss is away on vacation next week so you call their admin and say "you need to double-check my contact info if the boss is going to be out next week". They load up the boss' calendar to check and based on his presence next week then load up your info. Only once done, do they take the time to remember the boss didn't want you to know wether they are in or out. So you hear back, "sorry, can't tell you that, but you follow up with "OK, well can you still double check that my phone number is..."

If they respond quickly with a yes, then your file is still on their screen and the boss is in fact out next week. If there is a short pause while they look it up, then the opposite.

Re: Reading privileged memory with a side-channel

#474
post #341

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...

Just tested this on systems of varying age. Works on processors going back as far as 2007 (the oldest I have access to now is an Athlon 64 X2 6000+), but the example code relies on an instruction that the Atom D510 does not suport. Because Spectre seems to be an intrinsic problem with out-of-order execution, which is almost as old as the FDIV bug in intel processors, I would be very surprised if the Atom D510 did not…

Certain Atom CPUs have no speculative execution nor OoO execution.

Re: Reading privileged memory with a side-channel

#476
post #450

Earlier quoted context omitted.

Thank you for this. Would you say this applies to both Spectre and Meltdown, or one and not the other?

This is a general explanation of side channel attacks, as I understand.

Yes, this is a general explanation of side channel attacks against some kind of caching. The more specific example tries to be closer to the type of situation that happens in Spectre, but it is not a direct analogy.

Re: Reading privileged memory with a side-channel

#477

I wonder if the whole thing with enormously complex CPUs requiring deep pipelines which in turn requires complex speculation etc was a design mistake? Is there an alternative history where mainstream CPUs are equally fast with a dumber/simpler design?

Not that we currently know about. RISC instead of CISC is better here as it shortens the pipeline, but even RISC processors do speculative predictions due to the cost of waiting till a branch is fully decided.

Re: Reading privileged memory with a side-channel

#478
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 .

After reading that thread, I sort of wonder if this is the catalyst for the next tech bust. Prices on the basic building block of the modern tech industry (a server shard) going up 30%, or even more as shared/virtual services must be decommissioned for isolation? Surely it’s an alarmist thing to think and I don’t think it’s likely, but if you asked me yesterday the likeihood of an underlying security vulnerability ef…

would be interesting to look at public companies where server costs going up 20% would kill their profit margins.

Re: Reading privileged memory with a side-channel

#479

I wonder if the whole thing with enormously complex CPUs requiring deep pipelines which in turn requires complex speculation etc was a design mistake? Is there an alternative history where mainstream CPUs are equally fast with a dumber/simpler design?

Not that we currently know about. RISC instead of CISC is better here as it shortens the pipeline, but even RISC processors do speculative predictions due to the cost of waiting till a branch is fully decided.

What about more radically different designs? E.g Mill or others?

Re: Reading privileged memory with a side-channel

#480

An analogy that was useful for explaining part of this to my (non-technical) father. Maybe others will find it helpful as well. Imagine that you want to know whether someone has checked out a particular library book. The library refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out. What you do is follow the person…

I don't understand how this info can be used for getting what was inside the book? If my understanding of your explanation is correct, book name is analogous to memory address. When the victim (legit process) returned the book with name X (called free on the mem block X), the librarian (OS) erased all pages of the book and repurposed it for printing another book before handing it out to the evil dude(snoopy process).
Post reply on HN