1. 44
  1. 7

    we store immutable code and data on a content-addressed file-system called BlobFS. You access what you want by specifying its hash (really, the root of a Merkle tree, for fast random access). Then we have an abstraction layer on top, which components can use to access files by names and which, under the hood can verify signatures for those hashes.

    Yow! Anyone remember that what-filesystems-should-be-like thread from last week?

    1. 2

      It’s a lot like git FWIW

      1. 6

        At the API level, yeah. But Git is an immutable data store implemented on a regular filesystem. BlobFS is implemented at the disk-block level. Not only is that more efficient, it’s more secure because there is no way to go underneath it and mess with data. (Except for a process with some very rare capability of writing to disk blocks.) Which is important because BlobFS is where code is stored.

        Speaking of code, another interesting detail I saw in that article is that the ability to mark address pages as executable is a privilege that has to be granted to a process. Which rules out some more attack vectors in the majority of processes that don’t need to run JITs. (This is a bit like iOS.)

        1. 8

          Disclaimer: I’ve been working on Fuchsia for the past 5½ years.

          Even if you can write blocks it doesn’t matter because the Merkel roots are signed. This prevents offline tampering. The neat thing about using Merkel trees is that its cheap to update a part or all of a file and cheap to validate a read of part of a file.

          For JITs there are interesting opportunities to be able to separate the actual JIT compiler with the rights to write to executable pages into a separate process that is smaller, simpler, easier to audit. That’s hard though.

          1. 1

            At what level are the signatures? At the root of the filesystem, or on individual files?

            1. 2

              I forget the details. IIRC there’s a “package” abstraction that’s signed and the files within a package are verified against that package merkel root. One neat property of that - you don’t need to download a whole package to safely use parts of it - it can be the unit that you sign without needing to be the unit of delivery.

    2. 6

      So much stuff feels reinvented just so that Google could own the copyright. FIDL, Zircon, ffx, BlobFS, the component-and-package subsystem… I could easily imagine using off-the-shelf components for all of these, especially in the context of wanting to create a rich ecosystem of Free Software which is easy to port to new devices and empowers end users. Of course, Google doesn’t share my dreams.

      On a more technical note, I don’t understand why so much of the driver code is handwritten. We’ve had lightweight userspace GPU drivers ever since Gallium in Mesa, and it doesn’t make sense to rewrite so much stuff when the choice has already been made to use C++ and Rust rather than capability-safe languages.

      Speaking of which: Where’s the high-level capability-aware language where folks can write actors? Rewriting everything in order to gain capability-safety is worthwhile, but having to write high-level programs purely with FIDL invoked from a low-level language sounds horrible, and not like an improvement on the state of the art, which is writing C++ on Genode instead of on Fuchsia. Indeed, that’s the one question I want answered: Why should I target Fuchsia instead of Genode with my high-level capability-aware language?

      1. 4

        Fuchsia uses Mesa.

        1. 1

          There isn’t a production quality capability based kernel they could “just use”, blobfs is at its core a very simple file system such that an existing authenticated fs would likely need to be significantly rewritten anyway.

          1. 1

            There’s strong evidence that seL4 might be used in industry, as an example. Google wouldn’t have to use Genode to use seL4, either.