Hacker News Reader

That's a lot of work, but the instant it's in a rootkit everybody will be able to do it. 113 bytes is extracting an AES key from memory in about a minute.

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

>but the instant it's in a rootkit everybody will be able to do it.

This makes no sense. If you have the privileges to install a rootkit, there is no need to use any speculative execution exploit.

The first feature of a rootkit is to get root access. A userspace kernel-information leak utility would be very useful for this step.

Okay, we have differing definitions of what a rootkit is it seems.

They mean in the implementation of a rootkit.

we have yet to even find Specter in a kit, this will never see the light of day, especially since it is so easy to avoid (turn TSX off).

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.

113 bytes is extracting an AES key from memory in about a minute.

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

Of course if you are being targeted then the concern may go up, but I still think that attackers would have lower-hanging-fruit than this, seeing as setting up one of these reads to get one secret would itself require such intimate knowledge of your machine's configuration and state that they probably already know what they want.

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

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

What is it that programmers do? They automate complex tasks that take humans considerable effort.

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?

The conventional wisdom is that if a nation state wants your data badly enough it is game over. Even an air gap can apparently be bridged if you have the budget and you're patient and smart enough. It's root kits, booters, ransomware, exfiltration and script kiddies that you have to worry about in practice.

It's not what a nation does to it's own supply chain that a nations supply chain has to worry about.

Yes, and the point is how do we define "badly enough".

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.

History has repeatedly shown that "infeasible" attacks are really just difficult.

what's your opinion on package management communications? couldn't an eavesdropper on the network deduce quite a bit about your system's configuration? distribution of dates and sizes of packages downloaded seems like quite a leak.

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?

> while conveniently ignoring to mention the countless hours spent aligning everything just right

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.

The "nutty"ness comes from people getting frustrated with intel fucking up the security of yet another feature they promised, and intel's overall poor security record.

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.

At the level where large, security-centric organizations make decisions, these instances argue for getting AMD in the door like nothing else that I can recall. So, it's a good time for AMD to have such performant hardware and a process advantage. If it stays this way for a decade, I'll be able to put in a PO for AMD hardware...

The problem is, these leaky cache issues come from 'performant' hardware. It is the pipeline optimization that leads to the side channel.

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.

When the market rewards secure design, you can make that complaint. Since the market does not reward secure design, expect investments in security to be commensurate. You cannot have it both ways.

Not a complaint but merely stating the obvious.

The market is noticing that we're losing a whole lot of performance on Intel to these security-related mitigations, though...

Intel reports record profits again.

Thank you. Apparently, the stockholders agree with my assessment.

See here: https://news.ycombinator.com/item?id=22167267

I work for Intel (not speaking in my official capacity) and the AMD scare here is real.

This doesn't mean that Intel hasn't been affected negatively by the resurgence of AMD in the processor business. AMD is taking several billion dollars of revenue, and every dollar of that costs Intel much more than $1. A noticeable part of AMD's newfound competitiveness comes from the various performance taxes that Intel has had to pay for speculative execution mitigation.

It's worth noting, too, that Intel has diversified-- the processor business is only one very important business to Intel.

Profit in infrastructure is a delayed indicator, it talks about how the company was doing, not how is it doing now.

What do you do? The vulnerabilities don't apply to a vast majority of situations (meltdown was about the only one and it has been patched - more of a big).

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.

By your own numbers, this could translate to a 30-second AES key exfiltration in the cloud. This isn't a non-issue, even if you personally aren't affected.

you have to find the address first, which is a lot of rummaging around. you aren't just handed it. that is going to quite a bit, especially the program build any security measures in (eg, allocate at a random address). good luck with that.

Spread the key over a whole page with fec, implement the key recovery using non saved registers. Would be nice to avoid pre-emption and avoid leaking regs to ram. Perhaps last step could use avx to run a permutation.

it's easy to say vulnerabilities don't matter... when responsible disclosure results in fixes for those specific relevant systems for which actual executable Proof of Concepts were designed. The authors have the skill and knowhow to do this for new systems, and the surrounding knowhow and skills are not gained by merely reading the whitepaper that focusses on the exact nature of the side-channel. Similarily a paper from the field of say physics, will not hold your hand by having a huge appendix filled with the physics courses, exercises, ... the authors enjoyed as a student...

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

2^12 = 4096, or the x86 page size in bytes.

And as for why the page size is relevant for the L1 cache: Intel (and AMD, and most other modern CPUs) use a VIPT (Virtual Indexed Physical Tagged) L1 cache, where the virtual address (before the page table translation) is used to index the cache (this is faster since it can be done in parallel with the TLB lookup to get the physical address). To prevent the confusing situation where the same physical address has more than one index in the cache, only the bits of the address which do not change between the virtual address and the physical address can be used; these are the bits which correspond to the offset within the page.

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

Does this mean we could see 16x larger L1?

All of hardware is tradeoffs.

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 first line is key to so much. All of hardware is tradeoffs. There is no magic.

Thanks for the explanation, but I‘m not sure I got why this can happen:

> To prevent the confusing situation where the same physical address has more than one index in the cache

You can have several virtual addresses mapped to the same physical address. However, if you use bits that are not 1:1 mapped between those two to index into your cache, then you might end up with one virtual address getting cached in one place in L1, and the other getting cached in another place in L1. That would be bad, because you'd have two potentially inconsistent caches of the same memory.

> You can have several virtual addresses mapped to the same physical address.

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?

It does happen, and not just for two different processes.

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.

"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)"

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.

Reads data (indirectly) from cache - you can select cache slot.

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.

The paper talks about how in a VM environment, this attack allows reading the hypervisor’s memory, and that public clouds put in mitigations based on the early disclosure to them.

That feels like a big issue.

How do you disable TSX? I don't see a control register flag or an MSR.

MSR IA32_TSX_CTRL, introduced with a microcode update a while back.

Wow, it's not even in the SDM. Only docs I can find are: https://software.intel.com/security-software-guidance/insigh...

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