131–140 of 232 posts
This is a fantastic read. Timing attacks are insidious and tend to crop it in the oddest places. I first learned of them when learning how to securely compare strings (used a lot with passwords). A naive implementation means that you can easily guess if a character is correct depending on how fast the compare function returns.
I believe that you now know that every time you do this(comparing passwords as Strings) a puppy dies!
Earlier quoted context omitted.
Right, but at a cost of a leaky cache abstraction. Which is now hugely expensive to work around, making me question how that ever got approved if the security model was clearly leaking at that point (which has been known for the entirety of speculative execution, right?)
> if the security model was clearly leaking at that point The leak is only clear in retrospect. Many, many things are only clear after you see how they were done. It has been twenty years since processors with this vulnerability started appearing. Over those two decades, thousands of very smart engineers (including state-sponsored ones) have collectively spent millions of hours of analysis trying to find security fla…
> In the good old days*, the speed of processors was well matched with the speed of memory access...Over the ensuing 35 years, processors have become very much faster, but memory only modestly so: a single Cortex-A53 in a Raspberry Pi 3 can execute an instruction roughly every 0.5ns (nanoseconds), but can take up to 100ns to access main memory. In real-world terms, what's the fastest processor we could build today wh…
The problem isn't really the speed of the memory but its size. The planar nature of memory and the speed of light impose a latency of access on a pool of size N proportional to the square root of N. The L1 cache on your CPU has kept up in speed with the processor and is the same size as the memory computers had when computers could access their main memory quickly.
Earlier quoted context omitted.
That doesn't make a ton of sense to me. Aren't mainframe CPUs developed using modern techniques?
Actually, mainframe CPUs are developed using old techniques, which are all of a sudden interesting again. (-: See for starters this discussion about reinventing the AS/400: https://news.ycombinator.com/item?id=16053518
Earlier quoted context omitted.
You're exactly correct. This is why the browsers decreased timing resolution in javascript so that you couldn't time memory accesses accurately enough to tell if the address was cached or not.
Does that mean -another- slight performance drop ???
Consider an Olympic 100 metre sprinter. Today we time this event very accurately, I think it's to one hundredth of a second, using sophisticated technology.
But even if the judges used a much less accurate mechanical stopwatch, Usain Bolt wouldn't actually be slower, we'd just be less confident of how ridiculously fast he is.
In some special cases, timing things very accurately might be essential to a use of Javascript, but I can't think of any examples off the top of my head.
Earlier quoted context omitted.
Does that mean -another- slight performance drop ???
It means the only secure system is one where the performance of any given instruction is constant in all cases for that instruction.
This is great, but remember that it covers Meltdown, not Spectre. Meltdown is the more immediate disaster, but Spectre is the more batshit vulnerability. You really want to get your head around: * The branch target injection variant of Spectre if you want to get a sense of how amazing this vulnerability is: you can spoof the branch predictor to trick a target process into running arbitrary code in its address space!…
* https://lists.opensuse.org/opensuse-security-announce/2018-0... (https://news.ycombinator.com/item?id=16081366)
Future microcode updates mentioned:
* https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... (https://news.ycombinator.com/item?id=16079910)
Ok I think I understand the subtleties of these attacks now. But: can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? If that happened then none of these attacks would be possible. I got my computer engineering degree in 1999 and ended up going the computer science route making CRUD apps all day. I feel in my gut that some engineer, somewhere,…
> can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? From what I understand, it does happen on AMD, which is why AMD CPUs are not vulnerable to the more dangerous Meltdown attack (any code reading kernel / hypervisor host memory). Intel / ARM delays the checks until later, to the time when the speculated instructions are actually finalised an…
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...
I see now why the Spectre attack is so serious (reading out of bounds within the same process memory). I feel like there may be ways to catch unallocated memory access similarly to how protected memory works. But, that wouldn't help reads from allocated memory in runtime environments like for Javascript (where separate scripts in the same process space aren't meant to see each other's data). This is clearer to me now:
https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
Going forward, we may have to assume that security is only possible with true process isolation. For example this might put pressure on OSs to fix their slow context switching implementations to encourage the use of processes instead of threads. Beyond that, I can't see any easy way to fix the situation and am highly skeptical of things like compiler fixes, because there will likely always be another way to abuse various instructions to read outside memory boundaries.
Earlier quoted context omitted.
I believe that you now know that every time you do this(comparing passwords as Strings) a puppy dies!
Sorry. Is this crude? Don't really understand down votes.
Earlier quoted context omitted.
In a pipelined CPU, you want to start the memory fetches for which instructions to next feed into the instruction decoder, before the branch instruction has finished the execute stage. Otherwise every branch incurs a pipeline bubble.
If you're doing speculative memory fetches, wouldn't that also leave a measurable impact on the cache? Simply instead of MOV AX, [something that depends on secret value] as in the original Meltdown paper you'd need to use JMP [something that depends on secret value] to trigger the memory fetch in a branch that's not going to be used.
In the comments on the article the author argues: "Why don’t speculative instruction (and data) fetches introduce a vulnerability? Because unlike speculative execution they don’t lead to a separation between a read instruction and the process (whether a hardware page fault or a software bounds check) that determines whether that read instruction is allowed."
but that would seem to be confusing the details of Spectre with Meltdown (which is happening a lot right now). Spectre doesn't depend on unauthorized reads succeeding.