A call to reconsider memory address-space isolation in Linux

https://lwn.net/SubscriberLink/909469/95386a9171af0b46/

by chmaynard • 4 years ago

218 105 4 years ago

kramerger• 4 years ago

2-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• 4 years ago

It's 2-14% offset potentially by whatever the cost is of the other mitigations that it replaces, for whatever that's worth.

Filligree• 4 years ago

I’m just going to keep turning all mitigations off, thanks.

hinkley4• 4 years ago

Correct 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• 4 years ago

If I understand correctly the patch at the moment doesn't affect system calls at all, only entering and exiting virtual machines.

junon• 4 years ago

No. 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• 4 years 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• 4 years ago

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

pas• 4 years ago

unmapped pages cannot be speculatively executed "into"? (due to TLB flush? which happens during unmapping?)

mhh__• 4 years ago

"Good" speculative execution shouldn't be able to speculate isolated memory - isolation does work against Spectre.

Meltdown-type exploits (Older Intel and arm) can "see" across this isolation in some cases, which is why they were such an egregious mistake. Spectre is kind of inevitable whereas Meltdown isn't.

reacharavindh• 4 years ago

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

3232• 4 years ago

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

rafale• 4 years ago

That's super interesting. Does it use some special CPU feature? The CPU usually let code running in kernel context do whatever it wants.

galangalalgol• 4 years ago

I'm curious what software is telling the kernel no. What enforces this?

3232• 4 years ago

In Windows 10/11 the core of the Windows kernel can run in a virtual machine totally separated from the rest of the kernel.

HyperGuard takes advantage of VBS – Virtualization Based Security
Having memory that cannot be tampered with even from normal kernel code allows for many new security features
This is also what allows Microsoft to implement HyperGuard – a feature similar to PatchGuard that can’t be tampered with even by malicious code that managed to elevate itself to run in the kernel.

https://windows-internals.com/hyperguard-secure-kernel-patch...

leeter• 4 years ago

Not a Windows Kernel Dev. But my understanding is it's more a tripwire than anything else unless virtualization based security is turned on. If that is activated then the Kernel has complete isolation from non-MS drivers and can prevent them from accessing critical data structures. MS has a list of known drivers that don't work with this and prevents users from activating it if it will break things.

josephcsible4• 4 years ago

Drivers which run in kernel space are not allowed anymore to access whatever they want

I don't like this. It's one thing to have memory the kernel doesn't usually need be unmapped by default, but it's another to prevent you from mapping it when you do need it. This reeks of DRM.

colejohnson662• 4 years ago

Prior to Microsoft changing things with Vista, drivers were free to rummage about and break systems. Blue screens were a common thing back then because drivers weren't careful. It's why Vista had such a bad rap for breaking systems; It exposed the driver authors who didn't care about safety.

Also, why does every kernel-safety measure have to be seen as anti-user or DRM? You're free to disable it[0] if you wish, just like Apple's SIP. It's there to keep users who don't know anything safe. Would you like it if an innocent looking piece of software was able to hide itself from the user (read: you) and the OS?[1] Preventing such attacks doesn't sound anti-user to me.

[0] https://windowsloop.com/disable-enable-device-guard-windows-...

[1] https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...

matheusmoreira3• 4 years ago

No idea why you're being downvoted. This does sound like an anti-user feature. Stuff like this exists to protect third party software from our analysis and "tampering".

0xbadcafebee3• 4 years ago

but it's another to prevent you from mapping it when you do need it

How do you know if it's a user needing to use it, or an attacker pretending to be a user needing to use it?

badrabbit3• 4 years ago

Windows actually uses a cpu feature for kernel patch protection right? I remember trying to figure out why Linux doesn't.

pjmlp2• 4 years ago

On modern Windows, it actually always runs as guest on Hyper V, and thus many such protection mechanisms ping back on virtualization.

Secure kernel and driver guard are another features with similar protection level.

hinkley4• 4 years ago

And Windows needed that feature much, much earlier.

One of the open secrets about windows is that in the 3.1 to 98 era, quite a large percentage of system crashes were actually caused by Creative Labs’ audio drivers. Those guys could not produce stable software if their lives depended on it.

But I don’t blame CL for Windows being crash prone. Microsoft made a choice and a compromise to get popular. A permissive driver model made them more popular with customers. If you pander, then the rewards and the consequences are both yours to enjoy.

MS tried to have their cake and eat it too back then. They wanted everyone to think they were the most sophisticated and powerful company because they were the smartest company in the world (which was the internal dialog at the time according to insiders I interviewed), but at the same time that it was all dumb luck and they couldn’t control anything.

dralley• 4 years ago

The same was true with Windows Vista and Nvidia graphics drivers

https://www.engadget.com/2008-03-27-nvidia-drivers-responsib...

Stamp01• 4 years ago

Many successful companies and individuals fall into that trap of being unable to differentiate between talent and luck. I'm certainly not saying Microsoft doesn't employ plenty of very talented individuals. But it also takes some fortunate twists of fate to succeed, which were completely out of Microsoft's control. Success is never guaranteed.

l33t233372• 4 years ago

How can code be running in kernel mode if it doesn’t have unrestricted memory access?

johntb86• 4 years ago

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

UI_at_80x24• 4 years ago

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

0xbadcafebee3• 4 years ago

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

staticassertion8• 4 years ago

It would be nice to have a more trustworthy stack at every ring, I think.

slt20212• 4 years ago

your 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-instance...

0xbadcafebee3• 4 years ago

True, 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

fsflover• 4 years ago

If you care about security, Qubes OS is more secure, with its hardware virtualization: https://qubes-os.org.

hinkley4• 4 years ago

Somewhere, Andrew Tanenbaum is chewing popcorn. Loudly.

marcosdumay2• 4 years ago

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

intelVISA2• 4 years ago

muh MINIX backdoor

astrange3• 4 years ago

That's already running on the Intel PCH.

anonymouse0082• 4 years ago

I’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• 4 years ago

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

anonymouse0082• 4 years ago

Thanks kind stranger, I appreciate your patience!

aaaaaaaaaaab• 4 years ago

This is a good opportunity for Rust!

colejohnson662• 4 years ago

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

fooker2• 4 years ago

This is good for Bitcoin.

cztomsik• 4 years ago

rust has absolutely nothing to do with prevention of side-channel attacks

A call to reconsider memory address-space isolation in Linux

Related Stories