Hacker News Reader

Comment by mjamil | Hacker News Reader

Is anyone working on a microkernel design for privacy-sensitive devices (like phones) that would prevent outright this class of kernel-level arbitrary code execution exploits? We're stuck with iOS and Android for the foreseeable future, but is there hope that we'll get this right some day?

Actually, would a microkernel design even be sufficient? Given that hackers exploit deserialization, memory safety, and variable type confusion issues, there's still plenty of avenues for data corruption and data leakage.

View on HN

Many of the kernel issues exploited in iOS are caused indirectly by its microkernel architecture, namely, the use of "ports" for kernel to kernel and kernel to user land IPC. For example: https://bugs.chromium.org/p/project-zero/issues/detail?id=21... .

Microkernel vs monolithic kernel has little to do with this, IMO. The main issues are asynchronous complexity and memory safety.

Also, a lot of your most sensitive data lives in userland. If someone gets access to the iMessage sandbox and the message database files, that's your most sensitive and privileged data gone, no kernel touched.

And the userland is the worst possible combination of technology imaginable for this purpose - a memory unsafe language with a ton of magic dynamic features. You get the horrible serialization issues from Java & Ruby with the same old heap, stack and integer overflows we've come to love in C and mix in some of the runtime control flow from C++.

Yep, a number of people are, myself included. OSDev channels have a few people who talk about it. The Fuchsia folks are around, too, and are quite friendly people. They probably have the most hopeful chance of a widespread release, though admittedly I worry about the affiliation with Google getting in the way of pro-consumerism. Just my opinion though.

I wonder if some combination of Fuchsia, Titan, and Tensor would be sufficient to mitigate a baseband processor vulnerability.

Probably not. Processor vulnerabilities have the perpensity to affect most OSes because they're often pretty fundamental flaws in the basic CPU security mechanisms when discovered.

If I wasn't clear, I'm asking about vulnerabilities in the baseband processor (BBP), not the CPU.

The BBP is what makes a smartphone a phone, rather than a small tablet:

https://en.m.wikipedia.org/wiki/Baseband_processor

The thing about the BBP is that it is a second computer running its own proprietary OS (typically an RTOS) to handle the RF modem. The phone's main OS typically has no visibility into that second computer, even as root, but the reverse may not be true.

So I was wondering if any of Google's efforts to increase security can mitigate attacks that might come through this particular channel that lurks, Kuato like, just out of sight.

Apple mitigates baseband processor vulnerabilities by putting it behind what's essentially an IOMMU.

I must be missing something. I don't understand how that's supposed to help.

On other phones the baseband has full control of the AP because it can read and write to all of its physical RAM. With an IOMMU a compromised baseband can only control things inside its small view, rather than completely compromise everything running on your phone.

But doesn't the IOMMU itself become additional attack surface for compromising the kernel? At least, I've seen it suggested that the tradeoff to gain a bit of defense-in-depth isn't necessarily worth it.

Not having an IOMMU=baseband can access all of the AP's memory.

Having an IOMMU=baseband can only access a small section of memory marked for it, ideally.

Obviously, it's worth implementing this: it turns a baseband compromise from "instant game over" to "might be a problem, but the IOMMU needs to have been set up incorrectly or the code that deals with it needs to have a serious vulnerability".

Google is, with Fuchsia: https://fuchsia.dev

What are they doing?

The "marketing fluff" is here [0]. From my understanding, the relatively novel things they're doing at the lowest levels are making it a microkernel, and using a capability-based security model [1].

The former decreases the Ring 0 attack surface, and the latter makes it challenging to cause a confused deputy problem -- you know, the ol' classic "whoops this daemon running as root accidentally allowed a browser tab to read /etc/shadow." Or the time honored problem of a single exploit in one process giving access to all files (and in some cases, all processes' memory and resources) controlled by a given user. Capabilities also make it relatively easy to sandbox userspace code, and to reason about what it has access to. Kinda like containers, but as a core concept rather than tacked on a few decades into development.

Now these concepts aren't new, but they haven't been deployed or supported at the scale Fuchsia may end up at. Which obviously makes it a pretty exciting project in terms of real-world impact. That said, I believe there's been some speculation that part of the motivation for Fuchsia is to avoid the mess that is out-of-tree drivers on Android. So on the one hand, the kernel can be updated more easily, but on the other hand there may in practice be a lot more unpatchable binary blobs floating around doing important things.

For a more academic project that has many of the same security concepts there's seL4 [2], which has the additional bonus of doing some insanely clever formal verification of the kernelspace code [3]. They have formal proofs that the compiled machine code actually implements the specified of the security model correctly, which is the first of its kind AFAIK. They actually have a set of interactive tutorials for the platform [4], which are a great way to get a feel for how userspace works on a security-focused kernel.

As a disclaimer, I'm not associated with either project, and I'm sure my explanations will be ripped to shreds. My information comes purely from following the space in my free time.

0: https://fuchsia.dev/fuchsia-src/concepts/principles/secure

1: https://en.wikipedia.org/wiki/Capability-based_security

2: https://sel4.systems/

3: https://sel4.systems/Info/FAQ/proof.pml

4: https://docs.sel4.systems/Tutorials/

The Intel ME runs a microkernel but it is still exploitable (even if you "clean" it).

SEL4 and Fuchsia seem to have a security focus, but whether that results in real world difficult to exploit devices is unclear.

Though currently Android-based, grapheneos is planning to move towards a microkernel + virtualisation model eventually. I'd imagine this is several years away at least, though.

https://grapheneos.org/faq#roadmap

There's also sel4, a security focused version of the l4 microkernel which is apparently one of the only formally verified kernels.

https://sel4.systems/About/

I'm not aware of any microkernels for phones (I'm not sure that would help either), but Android has been sandboxing more and more processing [1] and started using some Rust at the system level [2] ever since the stagefright bug [3].

1: https://android-developers.googleblog.com/2019/05/queue-hard...

2: https://security.googleblog.com/2021/04/rust-in-android-plat...

3: https://en.wikipedia.org/wiki/Stagefright_(bug)

User-space ACE would still be enough to do something like this. All sorts of user-space apps have the relevant permissions and are not secured against attacks to the necessary extent to stop a state level actor.

Perhaps something like this: https://www.crowdsupply.com/sutajio-kosagi/precursor.

Or, just use Linux on the smartphone and harden it with a smartcard (Librem 5).

Here you go. Phone based on a high robustness microkernel.

https://hoyosintegrity.com/products-2/hoyos-phone-2/

I don't know why anyone would even bother to suggest such a thing when there's a second, completely-independent, unobservable computer running on every phone, with ring -1 access. Until we get rid of those, phones will continue to be the IDEAL surveillance tool for state-level actors. It's like the old saying about security: If you have access to the hardware, all bets are off. In our phones, the cell companies already have hardware-level access. It's almost like the government had a hand in developing the cell phone technology stack to make it so easy to use in this capacity... (Seriously, they did, but I don't want to go down the rabbit hole of finding links.)

I'm not convinced microkernels are the answwr but we do have QubesOS.

Reply on news.ycombinator.com