For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from:
* a hardware key (on hardware that supports it), which checks the signature of
* the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob.
* we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs).
* package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set.
* base packages are then launched upon demand.
This establishes a direct line of trust from the hardware key to the base packages.
For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software.
I’d go further and say it’s not possible to fully implement async/await without compiler help.
I got really far with stateful, back in 2016 [1]. Stateful was an attempt to write a coroutine library in a proc macro, which generated state machines, as opposed to using os primitives like green threading. This was back before the rust community really started working in this space. I ended up extracting the type system from rustc to do much of the analysis, but it ultimately failed due to how difficult it was to output rust code that respected the borrow checker rules. I also didn’t have anything like the pinning system, so I couldn’t catch move issues either.
It was a much better idea to just implement this in the compiler.
This is great news! I'm glad Servo found a place to land. Are you planning on sticking with the MPL-2.0 license, or are you also considering relicensing as well?
For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from:
* a hardware key (on hardware that supports it), which checks the signature of
* the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob.
* we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs).
* package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set.
* base packages are then launched upon demand.
This establishes a direct line of trust from the hardware key to the base packages.
For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software.
[1]: https://fuchsia.dev/fuchsia-src/concepts/security/verified_e...
[2]: https://theupdateframework.io/
[3]: https://chromium.googlesource.com/chromium/src.git/+/master/...