It's only really hard and messy for the first guy who implements it, after that it is much easier, albeit still fairly messy. I'm not saying we need to panic, but it's more than a "non-issue".
How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else?
That's what really irritates me about all these side-channels that have been found ever since the first Spectre/Meltdown --- they all demonstrate something flashy like "we read a key/password/secret/something important from memory in a few minutes" while conveniently ignoring to mention the countless hours spent aligning everything just right so they could show off the one "magic trick". In a lot of the cases there's barely even any control over where it reads.
Every time something like this comes up, I feel compelled to post some bytes from somewhere random in the memory of a random process on my machine to show just how much I care; here you go:
E8 7F 00 00 00 A1 64 30 40 00 89 45 D8 8D 45 D8
C4 20 00 00-CE 20 00 00-D8 20 00 00-E2 20 00 00
F8 20 00 00-00 21 00 00-0E 21 00 00-16 21 00 00
26 21 00 00-36 21 00 00-42 21 00 00-56 21 00 00
66 21 00 00-76 21 00 00-84 21 00 00-96 21 00 00
AA 21 00 00-00 00 00 00-FF FF FF FF-B4 16 40 00
C8 16 40 00-7C 20 00 00-00 00 00 00-00 00 00 00
EC 20 00 00-00 20 00 00-00 00 00 00-00 00 00 00
I don't mean to understate the difficulty of the task, but I've also seen probably tens of repros by now that use intimate knowledge of e.g. the kernel page allocator and known post-boot state of e.g. a firmware image flashed on millions of devices to drastically cut down the search space
If a university can accomplish this task with their funding and no urgent incentive, what is the nation state actor doing with their enormous budget?
Badly enough as in they can ever do it a few times a year against a few high-value targets, or badly enough that they can do it to "only" a few tens of millions a year?
Even end-to-end encrypted communications can be bypassed if the government wants them "badly enough". But the point is that with E2E encryption, they can no longer tap into and data mine the conversions of billions in real-time to fish for crimes.
Just like when fighting malware creators, the point of security is to keep raising the standards and the difficulty for the malicious actors.
It's really not that hard. E.g. people working on browser exploits have been working on exactly this for years and years, back when just having an out-of-bounds read due to a regular browser bug was the mechanism. Turns out that programs are absolutely chock full of pointers and it doesn't take long to run across one that points to what you are looking for. Especially because programs tend to have lots of data structures that end up pointing to more and more important data structures, funneling you into the guts of the program.
Sure, reverse engineering takes work, but blindly hunting in memory with no clue it is definitely not.
Side-channel attacks are basically a persistent out-of-bounds read mechanism. That is a very bad thing (TM).
There are literally thousands of people who work on this day in and day out, and millions in bug bounty programs out there.
perhaps package servers and package management software should round up the package size to hide the identity of the package? use oblivious transfer to hide the identity of the package from the package server itself?
This makes no sense. If you have the privileges to install a rootkit, there is no need to use any speculative execution exploit.
You also, don't get to extract constantly. You only get a shot when the data is in the LFB, so the program needs to be actively reading or writing it to keep it moving back and forth from L1 and L2, at least that is the way I read the paper.
Luckily there are other vendors who seem to know what they're doing: We just received our first batch of non-intel servers at work and have no intention of returning to intel for the foreseeable future. What they offer is simply not worth the risk. I expect more companies to follow suit.
There are cache architectures (such as pseudo random replacement) that are much more difficult to perform side channel attacks on, but have slightly lower performance.
Intel's problem has been its relentless pursuit of per clock performance, and that has led to some of these side channel attacks. Cache coherency on multi-core is hard.
My guess is that if the market share of Intel and AMD were swapped, you would see similar cache attacks on AMD.
It's worth noting, too, that Intel has diversified-- the processor business is only one very important business to Intel.
Unless you are running untrusted VM from others, you're not making a rational, knowledgeable decision.
Most people are just using this to falsely justify their Intel hate, similar to Microsoft in the 2000s.
2^12 = 4096, or the x86 page size in bytes.
(As an aside, this also limits the size of the L1 cache, which is why it hasn't grown much despite the L2 and L3 cache growing a lot; an 8-way set-associative VIPT cache with a 4KiB page size is limited to 32KiB, absent tricks like page coloring. Perhaps this will change if 64-bit ARM servers become popular, since they can only address the largest amount of memory when using a 64KiB page size, and this would make enterprise distributions default to that page size.)
> To prevent the confusing situation where the same physical address has more than one index in the cache
Ah yes, of course. Is this something that actually happens (e.g. because of processes sharing memory, OS hands out different virtual addresses pointing to the same physical memory) or theoretical in nature?
For example, a common trick to implement an efficient circular list for objects of varying size is to map the same physical addresses twice in adjacent locations. Then you can just use a pointer to the start of each object and have no special handling for the case where an object straddles the end of the allocated area.
A huge L1 would be slower to access. You might end up slowing down all memory accesses by a cycle (or more) just for accessing the large cache. You also have to find some place to put the thing in your floorplan, and route everything else around it. This may result in timing challenges in other parts of the chip, which might require additional delay to resolve.
A huge L1 would take up more space. This would increase area, reduce yield, and increase cost. Since in a multi-core chip each core has its own L1, you will have to pay this cost multiple times. Also, L2 caches are typically inclusive, so you would potentially need a much larger L2 to be able to accommodate all the extra information in these L1s.
These tradeoffs have to be studied with simulated experiments to make the right call. For programs with huge working set, maybe the added latency pays for itself because you have have fewer cache misses. For programs with good locality, maybe you end up losing performance. Maybe you save power by reducing misses, or maybe you waste more power because the cache is using more power. Maybe it's an insignificant area increase, or maybe it completely blows up your budget.
That looks conspicuously like the load/store port address aliasing size (look up "4K Aliasing"), which can be used to stall data availability while the conflict is resolved. I'll read up on this particular one, but there's a growing family of vulnerabilities with 12-bit address aliasing in their toolbox.
It is on you to make sure something interesting is in the cache, but if you can make your target execute, 12-bits is fairly good selectivity.
That feels like a big issue.
Glad it's possible to do this in virt now: used to be impossible to disable TSX (you could avoid advertising it via cpuid, but you couldn't actually prevent usage of the instructions).
This is another TSX (transactional memory) issue, and you can disable TSX without much of a problem.
The attacker basically needs to be running a binary on the machine (not JS in a browser or anything).
The leakage is extremely slow, about 225 byte/minute for ASCII text (a 4k page in 18 minutes). I'm not sure if that was an exact recovery either, just a probabilistic one. With noise reduction to enhance recovery, they said it took twice as long - so about 113 byte/minute.
It seems to be able to only be able to control the bottom 12-bits of the address to recover (but I didn't fully get why) and require the process to be either reading or writing the data to get it into L1 cache somehow, so just sitting in RAM isn't good enough.
attacker still needs to figure out an address (even with ASLR there is still a lot of guessing, and if you have really sensitive data, just move it every second until you wipe it).
Interesting, but kind of a non-issue.