I think the more interesting thing here is the fact that so much code in their repository appears to be bit-rotted or half baked, despite being documented. KASLR is mentioned all over the place but doesn't work and the answer is "we know, it's there only to stop it bit-rotting". You need to patch the system to do kernel debugging because otherwise the toolchain hangs. Syscalls are documented as enforcing security rules yet the actual checks are //TODO comments (and they are still willing to assign CVEs so apparently they just forgot?!). The syzcaller tool is advertised as working with Fuschia, yet despite trying multiple different versions he can't even compile them due to API churn. Apparently downloading and executed a binary isn't even an option, despite their vision being that Fuschia is a sea of components downloaded and run from the internet.

It's hard not to feel like maybe Google has lost the ability to develop operating systems. Fuschia has been in development for years now, it has no users outside of Google yet if you flick through their docs you'll notice a whole bunch of pages talking about deprecated components, migrations, etc. When I last looked at their docs, they read like it's been around for 20 years and has millions of apps, even though that's not true. Oh yeah and of course the giant BLM banners everywhere they have/used to have. Just checked, now those banners are replaced with "Honoring Asian Pacific American Heritage Month", lol. Apparently their vision of a futuristic OS is one in which every page in the docs has some random totally US centric bit of virtue signalling in it. No wonder they somehow can't even finish a microkernel, a design that reduces performance in return for a much smaller syscall surface area.

My takeaway from the article is that Fuchsia exposes a capability-based interface externally, but uses the old kind of privilege-checking inside the kernel. Once a single sloppy check was found, the game was over: a privilege escalation and planting of arbitrary code into the kernel followed.

Did I miss anything?

Something that I haven't seen brought up yet is the "weird C++ vtable layout." This is actually the "relative vtable layout" that's first described here: https://bugs.llvm.org/show_bug.cgi?id=26723, and is usable in clang via the -fexperimental-relative-c++-abi-vtables option.

The basic idea is that you don't need to waste a whole 64 bits for vtable entry, especially since you can usually assume that code within the same DSO will be within 32 bits of each other. So, instead, you do a 32-bit offset from a known address (the vtable's address) to get the function pointer, and in the rare case you need a cross-DSO entry, just emit a thunk for the symbol that's in the same DSO to get an address within 32 bits.

Disclaimer: I made some contributions to Fuchsia and I am clearly biased.

I am not sure why there's so much negativity around Fuchsia. From a technical point of view it's finally a serious attempt to do something new in the OS space. It might not be the right and perfect answer, but it might introduce new paradigms and maybe some fork of the project might be able to provide additional benefits for end users down the road. I know that there are lots of hobby/research projects trying out new stuff, but i think Fuchsia stands out because it might be able to land the innovation and make it accessible for a larger user base.

Fuchsia still makes me deeply nervous inside. I get that linux has plenty of problems, but it really feels like Google have started to write an OS for the purposes of (a) having better remote control over the software that users run, and (b) being able to be free of the GPL. Security is the panacea that lets this happen, but I'm really not sure that it will inherently be better: iOS has effectively this model and it hasn't stopped a large number of nation-state actors effectively abusing it for hiding rootkits on victim's phones. The trade off for this is flexibility: the only reason I use an Android phone is because I can, with the right 3rd party OS, actually have a linux-based pocket computer that trusts me rather than its vendor.

The people who work on fuchsia are very good engineers - I’ve worked with many of them in person. But the project itself has always been a staff retention project. It only existed to keep said engineers from going to a competitor. I don’t know how any understanding of fuchsia is possible without this crucial fact

Very nice right up on how unfinished and insecure Fuchsia is as a result of it being so unfinished.

Would be nice to see something like this on seL4 (in some OS like Sculpt, for example)

The objective of computer security seems to have shifted from preventing someone else from running unauthoirzed software on your computer to preventing you from running unauthorized software on your computer. I would not describe this as security.

It sounds like a really bad idea to have all software "components" be resolved, downloaded, and executed from over the internet. Seems like a supply chain/waterhole attack just waiting to happen.

Not to mention it would seem to sign away the devices ability to act autonomously or offline. Of course, with my views of Google, it seems very like them to design everything to constantly rely on them to even function.

Correct me if I'm wrong on any of this.

The great thing about Fuchsia is it's like a Google version of Plan 9.

The bad thing about Fuchsia is it's like a Google version of Plan 9.

Url changed from https://swarm.ptsecurity.com/a-kernel-hacker-meets-fuchsia-o..., which points to this.

You see, this is how you do job interview, not waiting for some HR schmuck to ask you leetcode questions over the span of 6 months.

Wow, it is surprising how awful every last bit of Zircon code reproduced here is. I have to guess the rest is about as bad.

This dreck would never pass code review at my shop.