A call to reconsider memory address-space isolation in Linux
lwn.net
lwn.net
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).
I would say it's 'a' kernel. The idea of there only being one kernel is probably a concept that makes for nice layered diagrams, but doesn't come close to describing reality because of the combinatorial complexity of options for different morphs of layering. Sort of like the OSI network layers model in that way.
> 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...
But I heard VBS has a ~10% overhead compared to not enable it. I wonder what does cost this. Enable hyperv itself didn't really cause observable difference though.
VBS also secures things like the scan timer/event and some other methods people used to use to disable it. http://uninformed.org/index.cgi?v=8&a=5&p=18 .
The performance impact shouldn't really be noticeable at all. All you have is some memory operations which are "Duplicated", but not really since COW. But i'm not that much of an expert on patchguard besides the really basic functions.
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.
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...
OP's point was about kernel patch protection
how do I disable that?
Virtualization based security, the technology enabling this, also enables DRM. It is currently required by Netflix for 4k resolution streaming.
I guess my question is, you seem to have a very hardline “everything” take that I don’t think extends to the real world
Any process? No. My processes? Yes. That includes "sensitive" memory like cryptographic keys.
You do have total access. You chose to install an OS that wants to limit it.
Most users don't want driver-freedom. They want user-freedom, that is easily achieved by keeping the kernel open source and replaceable.
If you want to break some in-kernel protection, you can just patch the kernel and remove it.
The original comment I replied to was about the Windows kernel.
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?
Secure kernel and driver guard are another features with similar protection level.
One of the reasons for the hardware requirements.
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.
https://www.engadget.com/2008-03-27-nvidia-drivers-responsib...
It was 'better' to just assume you were awesome and hope your luck held for years on end. And if it didn't, then you could tell a story about how talent got you big and bad luck took you out. No, it was luck both ways or skill both ways.
In theory you could work around all these protections, but it would be difficult and fragile.
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..
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.
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.
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.
Personally, I would rather see a kernel side MPU in feature CPUs
It's more like saying "refusing to leave your house because you're worried you might get mugged", which might actually be very reasonable if you live in a bad neighborhood, you're a common target of crime, etc. It may not be reasonable for many others.
But analogies are pretty rough in general.
> 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.
The reason we don't see these attacks is because everyone patched the major issues immediately. Further, attackers don't need to really go for these sorts of attacks, there are more reliable, well-worn methods for attacking browsers.
Please spell it out for me. Suppose I'm a typical desktop user, how is important information going to be stolen if I have mitigations turned off and JavaScript enabled? What state does my browser have to be in, and what actions do I have to take (or not take) for the attack to succeed? What likelihood is it that someone has deployed an attack that meets those requirements?
> Further, attackers don't need to really go for these sorts of attacks, there are more reliable, well-worn methods for attacking browsers.
So we agree it's OK to leave mitigations off and browse the web?
https://github.com/google/security-research-pocs/tree/master...
I don't imagine I'm going to explain it better than the many others who have already done so.
> What state does my browser have to be in, and what actions do I have to take (or not take) for the attack to succeed?
Your browser would have to be pretty old/ outdated since they've been updated to mitigate these attacks. Otherwise it's just necessary that you visit the attacker controlled website.
> What likelihood is it that someone has deployed an attack that meets those requirements?
That's not a simple question. Threat landscapes change based on a lot of factors. As I said earlier, we won't see these attacks because people have already patched and attackers have other methods.
> So we agree it's OK to leave mitigations off and browse the web?
You can do whatever you want, idk what you're trying to ask here. What is "OK" ? You will be vulnerable but unlikely to be attacked for the reasons mentioned. If you are "OK" with that that's up to you.
It's a really impractical attack outside of extremely targeted scenarios. It's not something real desktop end-users need to worry about. The mitigations slow down your system for zero benefit.
> You can do whatever you want, idk what you're trying to ask here. What is "OK" ?
Maybe re-read the thread from the start? The first guy I responded to was making an assertion that running without spectre/etc mitigations means you should turn off javascript.
The POC runs in visitors browsers lol it's a public demo that runs in your browser, not in a "carefully controlled research setup".
> that very probably don't contain anything of value
Lots of things are valuable other than passwords. Even just leaking addresses can be useful for further exploitation. The main issue is it's a violation of a security boundary.
> The first guy I responded to was making an assertion that running without spectre/etc mitigations means you should turn off javascript.
They said "I hope you <do that>". Presumably because it would also mitigate the issue.
In both cases: We know they are theoretically possible. We cannot say for sure when they'll emerge. Once they emerge, they can spread by themselves and become common.
I guess the place it doesn't hold up is that in the exploit case, they're intentionally engineered, and for a virus, well there's the Wuhan bioweapon conspiracy theory but no, it's more like random mutations cause it.
Properly engineered security fixes don't cause performance regressions, either because you find improvements to pay for them, or you get the hardware updated to make them cheaper. (That'd be PCID in this case.)
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.
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
Then we can replace the core API with a secl4 emulator.
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.
Therefore, the attack you are describing doesn't work.