9 ms·
A call to reconsider memory address-space isolation in Linux
- aaaaaaaaaaab 4y agoThis is a good opportunity for Rust!
- colejohnson66 4y agoNot arguing with you, but how? Rust is about memory safety, not memory isolation. It keeps me from writing out of bounds, but it does nothing to stop a malicious kernel module from stealing `SECRET_KEY` out of the kernel's local memory.
- fooker 4y agoThis is good for Bitcoin.
- cztomsik 4y agorust has absolutely nothing to do with prevention of side-channel attacks
- kramerger 4y ago2-14% performance drop sounds high, I understand people are sceptical. Maybe the subsystems can be structured in a different way to ease the effects of ASI? Personally, I would rather see a kernel side MPU in feature CPUs
- tptacek 4y agoIt's 2-14% offset potentially by whatever the cost is of the other mitigations that it replaces, for whatever that's worth.
- Filligree 4y agoI’m just going to keep turning all mitigations off, thanks.
- Veliladon 4y agoYou do you but I hope you've also turned off JavaScript in your web browser.
- netr0ute 4y agoI keep my important info on paper.
- coldpie 4y agoIs there any evidence of anyone actually attempting such an attack outside a carefully controlled research scenario? The number of stars that have to align for this theoretical attack to work in practice is so high that I don't think any normal desktop end-user has reason to worry about it. (Shared servers, co-hosted VMs, etc are a different story.)
- garaetjjte 4y ago
- hinkley 4y agoCorrect me if I’m wrong, but wouldn’t complicated page mapping affect the cost of system calls the most? Because each call causes two alterations to the MMU state. I wonder how this patch interacts with io_uring. If kernel call overhead keeps going up it will force people to find ways to avoid the overhead.
- gpderetta 4y agoIf I understand correctly the patch at the moment doesn't affect system calls at all, only entering and exiting virtual machines.
- junon 4y agoNo. This is unavoidable. Mapping physical pages into a local page table is expensive no matter how you spin it. Depending on the data structures, this means doubling the time in some cases to allocate a physical page, which is typically 4KiB. Large allocations mean multiple page allocations. It adds up.
- m000 4y ago> Sometimes, though, there will be a need to access sensitive memory. An important observation here, Weisse said, is that speculative execution will never cause a page fault. So, if the kernel faults while trying to do something with sensitive memory, the access is known to not be speculative; the kernel responds by mapping the sensitive ranges and continuing execution. So, is the isolation patch a real solution to speculative execution attacks? Or is it just adding another hurdle for the attacker to jump? I.e. (if I interpret this correctly) the attacker would just be forced to add a "priming" stage, where they will trick the kernel to map the sensitive ranges they need for their speculative attack. So the effectiveness of the patch boils down to (a) the feasibility of this priming stage, and (b) for how long can the attacker keep the mapped memory in place.
- e63f67dd-065b 4y agoI think the idea is that faults on sensitive pages are known to be good, because they can only come when running kernel code. They are unmapped when exiting from kernel code, so in theory there's no way for userspace to speculatively execute on those pages and leak sensitive memory. It does seem to be a good fix for the root cause of the problem, but I'm skeptical about the details. I haven't look through the patch set, but narrowing down what's sensitive and what isn't is going to be a monumental task.
- deleted 4y ago[deleted]
- pas 4y agounmapped pages cannot be speculatively executed "into"? (due to TLB flush? which happens during unmapping?)
- simcop2387 4y agoMy understanding is that this is because the tlb update can't be speculated through. That means that once speculative execution hits that barrier it will stop and can't then look at data that would be mapped in if speculation kept going. Basically there's a hard fence there that it won't/can't go past so if you do hit a page fault in kernel space on one of the unmapped pages you know it will be from an active and not speculative thread running.
- reacharavindh 4y agoNot a kernel developer. It sounds like a useful feature in some contexts(shared hosts, multi-tenant setups etc.), but useful to run without these constraints when it doesn't apply(HPC doing one thing using all available resources). Couldn't this feature be implemented as a feature flag in the kernel to say enable this if you need(and disable if you know what you're doing)? As a side benefit, over time if smart folks find a way to reduce the overhead from this feature close to negligible levels, the feature flag would become unnecessary..
- 323 4y agoWindows already does this for a number of years. Drivers which run in kernel space are not allowed anymore to access whatever they want, and Windows own kernel space data structures are protected against modifications by other kernel mode running code (kernel patch protection).
- l33t233372 4y agoHow can code be running in kernel mode if it doesn’t have unrestricted memory access?
- johntb86 4y agoThe page tables can be set up so kernel-mode code doesn't have access to all of memory. You could get around this by modifying the cr3 register to point to a different page directory, but that could cause problems whenever a context switch happens and cr3 is reverted. Microsoft also has PatchGuard, which could probably detect changes like that. In theory you could work around all these protections, but it would be difficult and fragile.
- rafale 4y agoThat's super interesting. Does it use some special CPU feature? The CPU usually let code running in kernel context do whatever it wants.
- galangalalgol 4y agoI'm curious what software is telling the kernel no. What enforces this?
- UI_at_80x24 4y agoIf I understand correctly, OpenBSD has done this for years too. IIRC Around the time that the first Specter vulnerability was announced OpenBSD patched all those possible variations too.
- 0xbadcafebee 4y agoPersonally I would rather we just lean more into microVMs. From a cloud computing perspective, I don't care what security Linux claims to have, because I just assume it is ineffective and move forward from there. We build systems using loosely-coupled, strongly-authenticated, temporary sessions, and it's very easy to enforce separation of concerns (and thus minimize attack surface).
- staticassertion 4y agoIt would be nice to have a more trustworthy stack at every ring, I think.
- slt2021 4y agoyour code may be secure, but your cloud neighbor or VM host may be not. if VM host machine is taken over, then your VMs are at risk too https://unit42.paloaltonetworks.com/azure-container-instances/ https://unit42.paloaltonetworks.com/azure-container-instance...
- 0xbadcafebee 4y agoTrue, but it's pretty rare for hypervisors to be exploited. In that Azure case the node itself maintained a connection to each VM, which kind of defeats the purpose of using VMs for isolation.... It's like having strong memory guarantees in Linux and then having an open socket from a root-owned process to every other process... like, maybe giving them a new attack vector to a SPOF isn't a great idea
- slt2021 4y agohypervisor exploitation exist, just as container escapes and every other runtime escape and escalation. Which is natural for cloud native app development. remember the shared security model, the lower stack of infra depends on cloud vendor, and it critically depends on hypervisor/OS/container runtime security and configuration hardening
- fsflover 4y ago
- hinkley 4y agoSomewhere, Andrew Tanenbaum is chewing popcorn. Loudly.
- deleted 4y ago[deleted]
- marcosdumay 4y agoNext in line, a plea for splitting the source tree into different repositories. Followed by a plea for stabilizing the core kernel API... Then we can replace the core API with a secl4 emulator.
- intelVISA 4y agomuh MINIX backdoor
- astrange 4y agoThat's already running on the Intel PCH.
- anonymouse008 4y agoI’m not smart enough to understand kernels, or how memory works at an operating system level, but does this have anything to do with Apple‘s recent announcement that all unallocated memory will be zeroed out? I’ve been wondering, albeit naïvely, if TikTok and Facebook have been scraping unallocated memory allocations to achieve “without achieving” listening in on our microphones and cameras. Siri is always listening / camera sometimes pops up before accessing photos and the unallocated recordings / visuals could still be there? It could explain the uncanny awareness and specificity of their ads / algos.
- valleyer 4y agoJust in case the downvotes didn't answer your question: no. Memory was already zeroed out before it crossed process boundaries. Apple's recent change is about zeroing it out even before it's reused within a process. (Freeing memory doesn't always give it back to the operating system; the userland allocator usually keeps a list of free blocks to be reused quickly.) Therefore, the attack you are describing doesn't work.
- anonymouse008 4y agoThanks kind stranger, I appreciate your patience!