27 ms·

A Kernel Hacker Meets Fuchsia OS

349 points by chrisdinn 4y ago

bitwize 4y ago
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.
- kramerger 4y ago
  The bad thing about Fuchsiais that it's a Google product. They may decide to kill it next week and switch to XNU or symbian or templeos and no one would be surprised.
  - layer8 4y ago
    That’s fine as long as it’s open source and a self-contained local piece of software (as Fuchsia is). The problem with Google killing products is that they’re closed source and/or require huge server resources and/or ML models.
    - e3bc54b2 4y ago
      From what I've read Fuschia is not at all self-contained. The UI is fully driven by and targeted towards Google the search and ecosystem. But those write-ups were years ago and there hasn't been new reviews with much UI focus since then.
      - layer8 4y ago
        You’re probably right, though for an OS that’s the kind of dependency people would prefer to have removed anyway.
      - surajrmal 4y ago
        Operating Systems are not a very well defined subject. Linux doesn't include a UI layer for instance and that isn't considered a problem. Being tied to a particular experience limits the potential applications of the OS, so in many ways I would consider the lack of opinionated experience a good thing. There is now a UI experience available as part of Fuchsia in the workstation product, but I wouldn't overly index on it as it's just one take on what you could use Fuchsia to build.
  - ryandvm 4y ago
    Google's proclivity for aggressively wiping the spaghetti off the wall is starting to work against it. I think maybe they need to start promising to open source any products they lose interest in.
- dhodell 4y ago
  Ironically, several folks who worked on Plan 9 later worked (or continue to work) at Google, although none of them worked on Fuchsia. <ramble> To me the major overlap between them is their designs are clearly informed by the contemporaneous shape of network architectures. Fuchsia is a take on what an OS design would be as a set of named microservices that can be routed. Plan 9 noticed network topologies of compute labs and clusters weren't too different, and both graphs could be represented in filesystems. The major visible difference to me is that the visibility of routing is much more apparent in Plan 9 than it is in Fuchsia. It's still a little difficult to understand how and where capabilities propagate through the system. Implementation-wise, FIDL is a much different take than 9P2K. Though much simpler, 9P2K forces every API to exist via a filesystem interface (many of the higher level protocols also involve quite a lot of string passing) and struggles with throughput of streaming operations. Individual FIDL APIs might have similar problems, but the message encoding itself is relatively more efficient. </ramble>
- deleted 4y ago
  [deleted]
binkHN 4y ago
Very nice right up on how unfinished and insecure Fuchsia is as a result of it being so unfinished.
- raggi 4y ago
  Was that your takeaway from reading it, or something else?
  - binkHN 4y ago
    My take away, but the author goes into a bit of detail on this.
- SpectralTheory 4y ago
  Better than being insecure by design, I would think.
  - ncmncm 4y ago
    Insecure is insecure. Or did you mean unfixably insecure?
    - coldtea 4y ago
      Parent means infixably and/or intentionally insecure.
- ThePowerOfFuet 4y ago
  The word you were looking for is _writeup_.
  - ge96 4y ago
    It's weird in my later 20s I started doing this, writing homophones. I at least get my then/their/effect right still.
    - 4y ago
deleted 4y ago
[deleted]
maverick74 4y ago
Would be nice to see something like this on seL4 (in some OS like Sculpt, for example)
- qayxc 4y ago
  That would be too hard, it's a kernel that's actually developed with security in mind and is subject to active research (e.g. by DARPA).
  - kramerger 4y ago
    If you try using sel4 in a project, you soon realise it is extremely limited and not at all useful for general purpose computers
    - maverick74 4y ago
      And yet it works on Genode/Sculpt! :) (yes... it's also a very limited OS... maybe someday it gets a decent GUI and starts to get more attention)
    - sydthrowaway 4y ago
      In what way?
    - exikyut 4y ago
      Hmm. By not providing a POSIX lemonade stand, would-be users are required to basically figure everything out for themselves; I wonder what the net impact of that is. On the one hand POSIX et al is effectively impossible to deploy in a secure way, so there is a reasonable argument for going back to the drawing board; but on the other hand there isn't really a well-defined go-to alternative How To Computer model that is friendly to provable security, so everyone has gets to reinvent that wheel every time Considering the contemporary status quo in terms of independently-implemented OS projects and platforms (eg, my ever-so-slightly-wobbly VxWorks-based TP-LINK consumer ADSL modem), I do wonder how good seL4 implementations end up working out in practice - the kernel might be rock solid, but what about all the bits on top of it, some of which presumably communicate with the outside world, consume various protocols, need to control the hardware in various ways (which includes relying upon reading the hardware state/status), etc?
ncmncm 4y ago
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.
- ncmncm 4y ago
  Downvote all you like, it is bad code all the same.
  - PaulDavisThe1st 4y ago
    If you said why, you'd be less likely to get downvoted. Hand-waving assertions of "that dreck" are not well judged.
    - ncmncm 4y ago
      Anybody who can look at the reproduced code and not recoil in disgust will be unlikely to understand a detailed criticism. Just read it!
      - skavi 4y ago
        I'd encourage you to have a go at explaining nonetheless. I'm sure there are at least a few critiques you have which many here would miss, even if they are competent. There's always value in code review, no?
    - Teckla 4y ago
      Speaking just for myself, after perusing Fuchsia source, the code seems eye-wateringly "clever," pretty much everywhere. I'm doubtful many people would be able to read it or contribute to it very effectively.
- Jyaif 4y ago
  I skimmed through the article and nothing stood out. Can you give an example of a piece of code you didn't like?
native_samples 4y ago
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.
- dec0dedab0de 4y ago
  It's hard not to feel like maybe Google has lost the ability to develop operating systems. Did they ever have that ability? I know they did a bunch of work for Android/Chrome OS. But both of those are Linux, have they tried to develop an OS from scratch before fuschia?
  - native_samples 4y ago
    Yes. Android is sufficiently different from a stock Linux distro that it absolutely counts as a unique operating system. ChromeOS is also unique in interesting ways, although less successful. It's certainly a production quality OS. Perhaps more importantly, both of those are complete and have real users who found value in them.
dmitrygr 4y ago
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
- baybal2 4y ago
  > It only existed to keep said engineers from going to a competitor. Who in this day, and hour tries to make an OS as a commercial product?
- tyingq 4y ago
  Does that mean you don't believe it's going to replace Android/AOSP? It's in some Nest devices right now.
  - pjmlp 4y ago
    Android is being ported into Fuchsia, https://android-review.googlesource.com/q/fuchsia https://android-review.googlesource.com/q/fuchsia What is more likely to happen is to replace Linux with the Fuchsia infrastructure.
  - rvz 4y ago
    I'm sure in the next 10 years it will replace both Android and ChromeOS. Starting with ChromeOS first, then Android itself. Otherwise, why is Fuchsia already running the Chrome web browser? [0] [0] https://9to5google.com/2022/03/04/full-google-chrome-browser-running-on-fuchsia/ https://9to5google.com/2022/03/04/full-google-chrome-browser...
    - leucineleprec0n 4y ago
      Right. This is what I think Fuchsia and Zircon probably are headed for long term but people really felt the compulsive contrarian need to stake out the experiment/retention project angle since so many saw the obvious but were hyperbolic about the timescale.
nine_k 4y ago
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?
- tyingq 4y ago
  Not familiar with capability-based practices, but wouldn't there always be a "if (has_this_capability(WHATEVER_CAPABILITY))" at the very bottom...one that could be sloppy? Doesn't something, somewhere do a comparison?
  - Commodore63 4y ago
    Capability based operating systems require that your program possess something, like a handle, in order to do something privileged. Don't have the handle, can't do the thing. It's not about consulting ACLs or bitmasks or whatever.
  - nine_k 4y ago
    Not necessarily. The core idea of capabilities is more like having a URL to a Web page. Using the URL (the capability), you can access the contents of the page. Inside the contents, you can possibly find other URLs (more privileges granted to you). But the URL happens to be something like an UUID, or a short link; looking at it, you cannot derive another URL (discover another "capability", not granted to you). In other words, a capability is like a key in a hash table, and unlike an index in an array.
    - why_only_15 4y ago
      Interesting. Is this in practice implemented as just capabilities being large numbers so it's impractical to guess them, or does the kernel have a table with all of a process's capabilities and when a message is sent to a process with capabilities the kernel adds them to the table? That is -- are capabilities just pieces of data in a message you can detect and try to use, or do they have to be added explicitly to a message to send them
ouid 4y ago
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.
- eklavya 4y ago
  The computer doesn’t know whether it’s you or somebody pretending to be you. Unauthorised execution should be possible but should be off by default, that’s 100% better for consumers. Sorry if I got your point wrong :)
- salawat 4y ago
  It absolutely is security. Job security. Enforced vendor dependence is all the rage. Try getting investor dosh without it. Not happening.
- zoul 4y ago
  I would guess you have never worked as a technical suppport for your family’s computers? Because even if I very much understand your point, not being able to run untrusted code absolutely is a security advancement in certain situations. It is SO refreshing and liberating to be able to say: Do whatever you want with it, it’s very hard to damage on the software side.
  - Iolaum 4y ago
    Agreed. However should Operating Systems for consumers only really cater to that use case? Because that is the problem IMO.
    - fartcannon 4y ago
      Yes, because the PR requires there be no ground given on this talking point.
  - dekhn 4y ago
    That's why I got my dad a chromebook. ChromeOS is a really well-engineered system- good enough that I never ever worried about security.
dvh 4y ago
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.
- deleted 4y ago
  [deleted]
- tech-historian 4y ago
  Marketing yourself has always been, and will continue to be, valuable. This marketing can take many forms.
Ruq 4y ago
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.
- katbyte 4y ago
  I would tend to agree, unless pinning is enforced/the default.
  - turminal 4y ago
    I think the idea is "ensuring software is always up to date", so no pinning by default.
    - metadat 4y ago
      Until they drop support for your hardware... Then what happens?
      - ketralnis 4y ago
        You have to chuck it in the bin and buy a new one, obviously. That's the state of the startphone world today, if you want to keep up on security updates
        myko 4y ago
        This is lamentable and I'd love to see longer periods of support for older devices, but I'm not sure what the ideal state is - beyond being able to install your own OS on your device, which will still require some level of support from someone. What's reasonable - 5 years of support? 10?
    - dhodell 4y ago
azalemeth 4y ago
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.
- deleted 4y ago
  [deleted]
- staticassertion 4y ago
  People say this about a lot of security things. Ultimately, a lot of security is about constraining systems, and that makes people nervous. When I got my first Android phone I could root it pretty trivially and run a fully customized ROM, these days it's not really practical on many devices. And for the same exact reason that I have less control over my phone, I also trust it radically more for my current threat model. iOS is maybe a counter-example. It relies a lot more on the walled garden, which helps a ton with malware, but not as much with "legit app got owned". It's worth noting that you explicitly believe Android to be "free-er", even though I would say the average Android device is safer. The two things aren't always at odds, and with Android it's also very device specific. Another good example is HSMs and TPMs. Many people fear that these devices are inherently untrustworthy, but they also drive a lot of important modern OS security. My position here is that Linux is something of a disaster with regards to security and it truly can not get better for a number of pretty fundamental reasons. If I had Google money I'd absolutely be investing in ways of removing Linux from my security boundaries - something they've already done to some extent with gvisor.
  - turminal 4y ago
    > People say this about a lot of security things Unfortunately those people are often correct.
dang 4y ago
Url changed from https://swarm.ptsecurity.com/a-kernel-hacker-meets-fuchsia-os/ https://swarm.ptsecurity.com/a-kernel-hacker-meets-fuchsia-o..., which points to this.
vander_elst 4y ago
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.
- hosteur 4y ago
  > I am not sure why there's so much negativity around Fuchsia. Easy: this is not the future we want. We don’t trust google. We don’t want an OS designed to further their goal of total control and surveillance capitalism.
  - qubex 4y ago
    It’s hilarious. I’ve been around long enough to remember people not trusting IBM and heralding Microsoft as the underdog with bright principles. Then it became Google being the white prince on a unicorn telling Micro$oft to eff off. For about a decade now we’re collectively in Not Trusting Google mode. “It’s all just a little bit of history repeatin’.”
    - vander_elst 4y ago
      But given that's open source shouldn't it be a bit better? If I don't agree with some parts of the OS I can fork the project and remove some stuff. Given that's open source you don't have to fully trust Google, you can check things yourself. I know I'm probably bring native, but I am hoping to see some changes in the space.
      - bobthecowboy 4y ago
        MIT means it's only open source for as long as Google feels like it should be (and only the parts they want to keep open). Older versions will still be around to fork from, but maintaining a fork of an OS is a pretty large task. Android is also open source, and is notably very difficult to simply fork and do your own thing and then actually use the thing, unless you happen to be a handset maker. My OS entirely driven by Google? No thanks, they're making enough of a mess of the web (and Android lately, TBF).
jcranmer 4y ago
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 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.
- ncmncm 4y ago
  Space for vtables is almost always negligible, especially so on 64-bit targets. So the main effect of inflated vtables is cache footprint. But where that matters most, you probably shouldn't be doing virtual calls anyway. Compilers don't get to say what you compile. People care about the speed of bad code almost as much as good code, and sometimes more: what bad code wastes, the compiler might be able to give some of back. Code that has a preponderance of vtables is usually bad code written by Java transplants who haven't learned the right way to code C++. But that code has to run, too.
  - surajrmal 4y ago
    Almost but not always. Fuchsia saw 1% memory savings (~20MiB) by enabling it: https://youtu.be/9HGKlDiJy8E https://youtu.be/9HGKlDiJy8E
  - pjmlp 4y ago
    Before Java came into the world I remember Turbo Vision, Powerplant, CSet++, OWL, MFC, Motif++, VCL, Tools.h++,...
  - Jyaif 4y ago
    > Space for vtables is almost always negligible, especially so on 64-bit targets. From the link: "I can report that a prototype of this was able to shrink Chromium's code size by 9%."

349 points by chrisdinn 4y ago

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.

kramerger 4y ago
The bad thing about Fuchsiais that it's a Google product. They may decide to kill it next week and switch to XNU or symbian or templeos and no one would be surprised.
- layer8 4y ago
  That’s fine as long as it’s open source and a self-contained local piece of software (as Fuchsia is). The problem with Google killing products is that they’re closed source and/or require huge server resources and/or ML models.
  - e3bc54b2 4y ago
    From what I've read Fuschia is not at all self-contained. The UI is fully driven by and targeted towards Google the search and ecosystem. But those write-ups were years ago and there hasn't been new reviews with much UI focus since then.
    - layer8 4y ago
      You’re probably right, though for an OS that’s the kind of dependency people would prefer to have removed anyway.
    - surajrmal 4y ago
      Operating Systems are not a very well defined subject. Linux doesn't include a UI layer for instance and that isn't considered a problem. Being tied to a particular experience limits the potential applications of the OS, so in many ways I would consider the lack of opinionated experience a good thing. There is now a UI experience available as part of Fuchsia in the workstation product, but I wouldn't overly index on it as it's just one take on what you could use Fuchsia to build.
- ryandvm 4y ago
  Google's proclivity for aggressively wiping the spaghetti off the wall is starting to work against it. I think maybe they need to start promising to open source any products they lose interest in.
dhodell 4y ago
Ironically, several folks who worked on Plan 9 later worked (or continue to work) at Google, although none of them worked on Fuchsia. <ramble> To me the major overlap between them is their designs are clearly informed by the contemporaneous shape of network architectures. Fuchsia is a take on what an OS design would be as a set of named microservices that can be routed. Plan 9 noticed network topologies of compute labs and clusters weren't too different, and both graphs could be represented in filesystems. The major visible difference to me is that the visibility of routing is much more apparent in Plan 9 than it is in Fuchsia. It's still a little difficult to understand how and where capabilities propagate through the system. Implementation-wise, FIDL is a much different take than 9P2K. Though much simpler, 9P2K forces every API to exist via a filesystem interface (many of the higher level protocols also involve quite a lot of string passing) and struggles with throughput of streaming operations. Individual FIDL APIs might have similar problems, but the message encoding itself is relatively more efficient. </ramble>
deleted 4y ago
[deleted]

binkHN 4y ago

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

raggi 4y ago
Was that your takeaway from reading it, or something else?
- binkHN 4y ago
  My take away, but the author goes into a bit of detail on this.
SpectralTheory 4y ago
Better than being insecure by design, I would think.
- ncmncm 4y ago
  Insecure is insecure. Or did you mean unfixably insecure?
  - coldtea 4y ago
    Parent means infixably and/or intentionally insecure.
ThePowerOfFuet 4y ago
The word you were looking for is _writeup_.
- ge96 4y ago
  It's weird in my later 20s I started doing this, writing homophones. I at least get my then/their/effect right still.
  - 4y ago

deleted 4y ago

[deleted]

maverick74 4y ago

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

qayxc 4y ago
That would be too hard, it's a kernel that's actually developed with security in mind and is subject to active research (e.g. by DARPA).
- kramerger 4y ago
  If you try using sel4 in a project, you soon realise it is extremely limited and not at all useful for general purpose computers
  - maverick74 4y ago
    And yet it works on Genode/Sculpt! :) (yes... it's also a very limited OS... maybe someday it gets a decent GUI and starts to get more attention)
  - sydthrowaway 4y ago
    In what way?
  - exikyut 4y ago
    Hmm. By not providing a POSIX lemonade stand, would-be users are required to basically figure everything out for themselves; I wonder what the net impact of that is. On the one hand POSIX et al is effectively impossible to deploy in a secure way, so there is a reasonable argument for going back to the drawing board; but on the other hand there isn't really a well-defined go-to alternative How To Computer model that is friendly to provable security, so everyone has gets to reinvent that wheel every time Considering the contemporary status quo in terms of independently-implemented OS projects and platforms (eg, my ever-so-slightly-wobbly VxWorks-based TP-LINK consumer ADSL modem), I do wonder how good seL4 implementations end up working out in practice - the kernel might be rock solid, but what about all the bits on top of it, some of which presumably communicate with the outside world, consume various protocols, need to control the hardware in various ways (which includes relying upon reading the hardware state/status), etc?

ncmncm 4y ago

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.

ncmncm 4y ago
Downvote all you like, it is bad code all the same.
- PaulDavisThe1st 4y ago
  If you said why, you'd be less likely to get downvoted. Hand-waving assertions of "that dreck" are not well judged.
  - ncmncm 4y ago
    Anybody who can look at the reproduced code and not recoil in disgust will be unlikely to understand a detailed criticism. Just read it!
    - skavi 4y ago
      I'd encourage you to have a go at explaining nonetheless. I'm sure there are at least a few critiques you have which many here would miss, even if they are competent. There's always value in code review, no?
  - Teckla 4y ago
    Speaking just for myself, after perusing Fuchsia source, the code seems eye-wateringly "clever," pretty much everywhere. I'm doubtful many people would be able to read it or contribute to it very effectively.
Jyaif 4y ago
I skimmed through the article and nothing stood out. Can you give an example of a piece of code you didn't like?

native_samples 4y ago

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.

dec0dedab0de 4y ago
It's hard not to feel like maybe Google has lost the ability to develop operating systems. Did they ever have that ability? I know they did a bunch of work for Android/Chrome OS. But both of those are Linux, have they tried to develop an OS from scratch before fuschia?
- native_samples 4y ago
  Yes. Android is sufficiently different from a stock Linux distro that it absolutely counts as a unique operating system. ChromeOS is also unique in interesting ways, although less successful. It's certainly a production quality OS. Perhaps more importantly, both of those are complete and have real users who found value in them.

dmitrygr 4y ago

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

baybal2 4y ago
> It only existed to keep said engineers from going to a competitor. Who in this day, and hour tries to make an OS as a commercial product?
tyingq 4y ago
Does that mean you don't believe it's going to replace Android/AOSP? It's in some Nest devices right now.
- pjmlp 4y ago
  Android is being ported into Fuchsia, https://android-review.googlesource.com/q/fuchsia https://android-review.googlesource.com/q/fuchsia What is more likely to happen is to replace Linux with the Fuchsia infrastructure.
- rvz 4y ago
  I'm sure in the next 10 years it will replace both Android and ChromeOS. Starting with ChromeOS first, then Android itself. Otherwise, why is Fuchsia already running the Chrome web browser? [0] [0] https://9to5google.com/2022/03/04/full-google-chrome-browser-running-on-fuchsia/ https://9to5google.com/2022/03/04/full-google-chrome-browser...
  - leucineleprec0n 4y ago
    Right. This is what I think Fuchsia and Zircon probably are headed for long term but people really felt the compulsive contrarian need to stake out the experiment/retention project angle since so many saw the obvious but were hyperbolic about the timescale.

nine_k 4y ago

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?

tyingq 4y ago
Not familiar with capability-based practices, but wouldn't there always be a "if (has_this_capability(WHATEVER_CAPABILITY))" at the very bottom...one that could be sloppy? Doesn't something, somewhere do a comparison?
- Commodore63 4y ago
  Capability based operating systems require that your program possess something, like a handle, in order to do something privileged. Don't have the handle, can't do the thing. It's not about consulting ACLs or bitmasks or whatever.
- nine_k 4y ago
  Not necessarily. The core idea of capabilities is more like having a URL to a Web page. Using the URL (the capability), you can access the contents of the page. Inside the contents, you can possibly find other URLs (more privileges granted to you). But the URL happens to be something like an UUID, or a short link; looking at it, you cannot derive another URL (discover another "capability", not granted to you). In other words, a capability is like a key in a hash table, and unlike an index in an array.
  - why_only_15 4y ago
    Interesting. Is this in practice implemented as just capabilities being large numbers so it's impractical to guess them, or does the kernel have a table with all of a process's capabilities and when a message is sent to a process with capabilities the kernel adds them to the table? That is -- are capabilities just pieces of data in a message you can detect and try to use, or do they have to be added explicitly to a message to send them

ouid 4y ago

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.

eklavya 4y ago
The computer doesn’t know whether it’s you or somebody pretending to be you. Unauthorised execution should be possible but should be off by default, that’s 100% better for consumers. Sorry if I got your point wrong :)
salawat 4y ago
It absolutely is security. Job security. Enforced vendor dependence is all the rage. Try getting investor dosh without it. Not happening.
zoul 4y ago
I would guess you have never worked as a technical suppport for your family’s computers? Because even if I very much understand your point, not being able to run untrusted code absolutely is a security advancement in certain situations. It is SO refreshing and liberating to be able to say: Do whatever you want with it, it’s very hard to damage on the software side.
- Iolaum 4y ago
  Agreed. However should Operating Systems for consumers only really cater to that use case? Because that is the problem IMO.
  - fartcannon 4y ago
    Yes, because the PR requires there be no ground given on this talking point.
- dekhn 4y ago
  That's why I got my dad a chromebook. ChromeOS is a really well-engineered system- good enough that I never ever worried about security.

dvh 4y ago

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.

deleted 4y ago
[deleted]
tech-historian 4y ago
Marketing yourself has always been, and will continue to be, valuable. This marketing can take many forms.

Ruq 4y ago

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.

katbyte 4y ago
I would tend to agree, unless pinning is enforced/the default.
- turminal 4y ago
  I think the idea is "ensuring software is always up to date", so no pinning by default.
  - metadat 4y ago
    Until they drop support for your hardware... Then what happens?
    - ketralnis 4y ago
      You have to chuck it in the bin and buy a new one, obviously. That's the state of the startphone world today, if you want to keep up on security updates
      - myko 4y ago
        This is lamentable and I'd love to see longer periods of support for older devices, but I'm not sure what the ideal state is - beyond being able to install your own OS on your device, which will still require some level of support from someone. What's reasonable - 5 years of support? 10?
  - dhodell 4y ago

azalemeth 4y ago

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.

deleted 4y ago
[deleted]
staticassertion 4y ago
People say this about a lot of security things. Ultimately, a lot of security is about constraining systems, and that makes people nervous. When I got my first Android phone I could root it pretty trivially and run a fully customized ROM, these days it's not really practical on many devices. And for the same exact reason that I have less control over my phone, I also trust it radically more for my current threat model. iOS is maybe a counter-example. It relies a lot more on the walled garden, which helps a ton with malware, but not as much with "legit app got owned". It's worth noting that you explicitly believe Android to be "free-er", even though I would say the average Android device is safer. The two things aren't always at odds, and with Android it's also very device specific. Another good example is HSMs and TPMs. Many people fear that these devices are inherently untrustworthy, but they also drive a lot of important modern OS security. My position here is that Linux is something of a disaster with regards to security and it truly can not get better for a number of pretty fundamental reasons. If I had Google money I'd absolutely be investing in ways of removing Linux from my security boundaries - something they've already done to some extent with gvisor.
- turminal 4y ago
  > People say this about a lot of security things Unfortunately those people are often correct.

dang 4y ago

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

vander_elst 4y ago

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.

hosteur 4y ago
> I am not sure why there's so much negativity around Fuchsia. Easy: this is not the future we want. We don’t trust google. We don’t want an OS designed to further their goal of total control and surveillance capitalism.
- qubex 4y ago
  It’s hilarious. I’ve been around long enough to remember people not trusting IBM and heralding Microsoft as the underdog with bright principles. Then it became Google being the white prince on a unicorn telling Micro$oft to eff off. For about a decade now we’re collectively in Not Trusting Google mode. “It’s all just a little bit of history repeatin’.”
  - vander_elst 4y ago
    But given that's open source shouldn't it be a bit better? If I don't agree with some parts of the OS I can fork the project and remove some stuff. Given that's open source you don't have to fully trust Google, you can check things yourself. I know I'm probably bring native, but I am hoping to see some changes in the space.
    - bobthecowboy 4y ago
      MIT means it's only open source for as long as Google feels like it should be (and only the parts they want to keep open). Older versions will still be around to fork from, but maintaining a fork of an OS is a pretty large task. Android is also open source, and is notably very difficult to simply fork and do your own thing and then actually use the thing, unless you happen to be a handset maker. My OS entirely driven by Google? No thanks, they're making enough of a mess of the web (and Android lately, TBF).

jcranmer 4y ago

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

ncmncm 4y ago
Space for vtables is almost always negligible, especially so on 64-bit targets. So the main effect of inflated vtables is cache footprint. But where that matters most, you probably shouldn't be doing virtual calls anyway. Compilers don't get to say what you compile. People care about the speed of bad code almost as much as good code, and sometimes more: what bad code wastes, the compiler might be able to give some of back. Code that has a preponderance of vtables is usually bad code written by Java transplants who haven't learned the right way to code C++. But that code has to run, too.
- surajrmal 4y ago
  Almost but not always. Fuchsia saw 1% memory savings (~20MiB) by enabling it: https://youtu.be/9HGKlDiJy8E https://youtu.be/9HGKlDiJy8E
- pjmlp 4y ago
  Before Java came into the world I remember Turbo Vision, Powerplant, CSet++, OWL, MFC, Motif++, VCL, Tools.h++,...
- Jyaif 4y ago
  > Space for vtables is almost always negligible, especially so on 64-bit targets. From the link: "I can report that a prototype of this was able to shrink Chromium's code size by 9%."