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

551–560 of 639 posts

Re: Reading privileged memory with a side-channel

#551

Post by caf »

314 wrote: post #531
bloorp wrote: post #217

Earlier quoted context omitted.

As I read through the meltdown paper, it looks really difficult to have the security we want and the performance we want at the same time. It's pretty crazy, but here's my limited understanding: There's a huge shared buffer between two threads. 256 * 4K. One thread reads a byte of kernel memory, literally any byte it wants, and it then reads one of those 4K pages from that buffer in order to cache that one memory pag…

Not allow user processes to recover from a SEGV. The attack depends on a signal hander that traps the signal and resumes execution. If this is disabled then the attack will not work. This would affect two types of systems: 1. Badly written code where bugs are being masked by the handler. 2. Any kind of virtualization? So, for cloud providers it looks like a 30% performance hit, but for the rest of us I would rather h…

The attacks do not rely on recovering from SIGSEGV. The speculated execution that accesses out-of-bounds or beyond privilege level happens in a branch that's predicted-taken but actually not-taken, so the exception never occurs.

Re: Reading privileged memory with a side-channel

#552

Post by gpderetta »

webaholic wrote: post #235
static_noise wrote: post #121

Earlier quoted context omitted.

Only if your speculative reads do cause irreversible side-effects on those caches. You could implement them in a way that doesn't modify the caches... but that would be complicated and probably use more power and have lower performance.

One of the main reasons for speculative execution is to fetch data into the caches ahead of them being needed. If you don't modify the cache, then you throw that away. May be one way would be to use a smaller, separate cache for speculative execution and then copy that value to the regular cache once speculation is confirmed? This would add a one cycle latency for cache-to-cache transfer but there might be better way…

It is not enough. The cache line still need be evicted (or at least marked as no longer exclusive) from other cpus, so the side effect is still visible.

Re: Reading privileged memory with a side-channel

#553

Post by alkonaut »

mike_hearn wrote: post #546
alkonaut wrote: post #479

Earlier quoted context omitted.

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

The Mill does prediction: https://millcomputing.com/docs/prediction/ It has to. The problem is the speed of light here, not a simple slipup by a CPU designer.

So all that needs to be done is make 64GB L1 on the die...

Re: Reading privileged memory with a side-channel

#554

Post by 314 »

caf wrote: post #551
314 wrote: post #531

Earlier quoted context omitted.

Not allow user processes to recover from a SEGV. The attack depends on a signal hander that traps the signal and resumes execution. If this is disabled then the attack will not work. This would affect two types of systems: 1. Badly written code where bugs are being masked by the handler. 2. Any kind of virtualization? So, for cloud providers it looks like a 30% performance hit, but for the rest of us I would rather h…

The attacks do not rely on recovering from SIGSEGV. The speculated execution that accesses out-of-bounds or beyond privilege level happens in a branch that's predicted-taken but actually not-taken, so the exception never occurs.

Ah, ok - then I read the paper wrongly. i’ll go back and have another look.

Edit: yes, I missed the details in section 4.1 when I skimmed through. I’m not familiar with the Kocker paper, but I assume the training looks like this?

for(int i=0 i<n; i++) if(i==n-1) do_probe();

Re: Reading privileged memory with a side-channel

#555

Post by gpderetta »

richardwhiuk wrote: post #477
alkonaut wrote: post #469

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.

The vulnerability window is proportional to the size of the reorder buffer (hundreds of instructions); the pipeline length (tens of stages) is not important (except on strictly in order CPUs with no reorder buffer I guess).

Also modern OoO CISCs and RISCs have very similar pipeline depths for the same performance/power budget.

Re: Reading privileged memory with a side-channel

#556

Post by gmueckl »

mike_hearn wrote: post #543
gmueckl wrote: post #290

Earlier quoted context omitted.

There does not need to be a performance hit, but cache complexity must rise: speculative execution must use a separate cache for any data that was fetched speculatively. Only when that branch is truly accepted must that data enter the "real" cache. As long as speculative execution does not go on for too long, these secondary caches can stay really tiny (a handful of cache lines maybe).

Unclear. From the Spectre paper: More broadly, potential counter- measures limited to the memory cache are likely to be insufficient, since there are other ways that speculative execution can leak information. For example, timing ef- fects from memory bus contention, DRAM row address selection status, availability of virtual registers, ALU ac- tivity, and the state of the branch predictor itself need to be considered…

I will be highly impressed if anyone managed to pull of a reliable and generic side channel attack based on the hardware you listed. Most of what you describe is squarely in the realm of tinfoil hattery.

DRAM and the memory bus is also affected by DMA operations running independently of the CPU.

Power consumption? There is no hardware available to measure that, let alone at the time resolution required. If you have to first attach a GHz bandwidth oscilloscope to the computer you might as well just reboot it or dump its RAM contents or whatever.

Forget about reprogramming a Wi-Fi chip. They operate on narrow channels in the 2.4GHz range and have fixed hardware for modulation. You would at least have to force the CPU to switch to the right frequency and then be lucky enough that it radiates a signal that demodulated to something sensible within the Wi-Fi hardware. This is physically impossible on current hardware.

Also, on a different note, we cannot sacrifice performance willy-nilly for the sake of a bit of potential security gains. A 30% performance loss on servers means that the counter move is to consume 30% more power to maintain current levels of operation in a data center. This energy needs to be generated, which means that someone is burning oil or gas for it with all the consequences. In essence, the current patches will result in an extra thousands or millions of tons of CO2 in the atmosphere. More efficient replacement hardware will eventually produced with extra environmental impact. We need to find ways to avoid that. Soon.

Re: Reading privileged memory with a side-channel

#557

Post by richardwhiuk »

alkonaut wrote: post #553
mike_hearn wrote: post #546

Earlier quoted context omitted.

The Mill does prediction: https://millcomputing.com/docs/prediction/ It has to. The problem is the speed of light here, not a simple slipup by a CPU designer.

So all that needs to be done is make 64GB L1 on the die...

Not possible - the physical size of 64GB (even at nm scale) means that the time it takes for a signal to traverse it causes memory to take a long time to access, meaning you need a L0 cache to maintain performance.

Re: Reading privileged memory with a side-channel

#559

Post by loulan »

caf wrote: post #315
tankenmate wrote: post #271

Earlier quoted context omitted.

But somehow you have to get that kernel address in the first place in order to alias it in the BTB. How do you get that without root?

They test how a series of branches are predicted after returning from a hypercall, which lets them basically dump out the state of the BTB. From that, and knowledge of where the branches are in the hypervisor binary (the binaries themselves aren't really a secret, only the relocated load address is) they can figure out the load address of the hypervisor. See the section "Reading host memory from a KVM guest / Locatin…

I've tried reading it and I still find all of this very confusing. Could you ELI5?

Re: Reading privileged memory with a side-channel

#560

Post by TickleSteve »

Godel_unicode wrote: post #417
cthalupa wrote: post #414

Earlier quoted context omitted.

I don't think you understand the bug here. 1) https://spectreattack.com/ : "Spectre tricks other applications into accessing arbitrary locations in their memory. " Spectre does not let you execute code in another guest 2) Spectre is not javascript specific. I am not sure why you think it is, beyond the fact a PoC was written in js

I don't think you understand my point. You should reread my post, especially the first sentence. It's first and alone for a reason; not sharing hardware is an effective mitigation against vulnerabilities in shared hardware. Obviously it's not just a js bug, there are other PoCs in other languages. I never said anything about executing code in another guest, not sure where you got that from.

Spectre is exploitable from processes, not just containers.... containers are equivalent to processes from it's point-of-view as the kernel is shared.

So... you may be able to go native to avoid having neighbours, but this does not prevent other processes exploiting your process. To do that you need to prevent any downloadable code from running.

This of course is possible and is the entire reason why the ARM document explains that most embedded systems are not affected due to the fact that they will not download and execute code (of any form).

Post reply on HN