[londons_explore]

I like the idea of it being possible. Just because it's a feature doesn't mean you have to use it.

For one thing, I assume such a system would have the ability to pin certain versions/hashes. If I (the user) can pin a set of hashes that are allowed to run, then I don't care where the actual resources are downloaded from.

Alternatively, if I can give a certificate I trust of someone else to give a 'realtime' list, that would also satisfy my needs.

[wittrock]

Hi there, I work on Fuchsia, specifically on our Software Delivery system [1].

You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products.

The ability to run code on demand is really valuable for our development flows and quick prototyping: built a new test or experiment? No need to update your device, just try to run it, and it runs!

[1]: https://fuchsia.dev/fuchsia-src/get-started/learn/intro/pack...

[erickt]

I also work on Fuchsia’s Software delivery team.

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

[a1369209993]

(At this point it's less "assume good faith" and more "halfheartedly check for the unlikely event that any good faith is present", but...)

How do you insure that the end user is able to replace the hardware key and bootloader with one of their own devising (and generally to tamper with arbitrary parts of system) without a remote vendor/employer/DRM firm being able to prevent or detect it?