On 11/21/20 8:26 PM, Heiser, Gernot (Data61, Kensington NSW) wrote: > On 20 Nov 2020, at 03:28, Demi M. Obenour <[email protected]> wrote: >> >> The first is an explanation for why the restrictions stated are >> acceptable. For instance, it is clear that the targeted systems are >> static. Why is dynamism not required? Is it because these systems >> are created with a single purpose in mind, and so do not need the >> level of extensibility that a dynamic system offers? > > As the design document states: It’s meant to be simple but sufficient for the > target domains. More generality means more complexity. The proposed model > should serve almost all present use cases. Even Cog System’s “ultra-secure > phone" fits this model: All the dynamicism, such as run-time installable > apps, happen inside a virtual machine with an Android guest. From the seL4 > PoV, the phone is a simple, static architecture with a fixed number of > protected components: the “use VM” containing a full Android system with > virtual drivers, the VMM, a console, a I/O multiplexing component, a “driver > VM” (which should eventually become individual driver components), a network > encryption component and a storage encryption VM. If the Platform supports > this use case, it will definitely support most others.
That makes sense. Would it be possible to include a “non-goals” section, for the benefit of readers who have not attended the seL4 Summit? > For the (presently very small) class of deployments that need more > generality, a different framework is needed. Such more general frameworks may > be standardised in the future (and may or may not be extensions of the Core > Platform), but for now this is not the aim. If you want a system where a > fully general OS is needed, Genode is likely your best choice (at the expense > of losing most of the assurance). That’s understandable. A fully general OS is a far more difficult task, even if it does not attempt to conform to POSIX or other legacy standards. It certainly does not belong in “a first step”. >> The second is the ability to forcibly reset a protection domain to >> its initial state. […] > > As the RFC clearly spells out, this is “a first step”, we won’t get very far > trying to boil the ocean. Re-initialising components is definitely planned, > but for a future release (see the last few minutes of my talk at the seL4 > Summit: > https://www.youtube.com/watch?v=khcjH77riGA&list=PLtoQeavghzr1Z3mF5B-f_xnFm81MPPwA-&index=4 > > <https://www.youtube.com/watch?v=khcjH77riGA&list=PLtoQeavghzr1Z3mF5B-f_xnFm81MPPwA-&index=4>). Indeed, “boiling the ocean” is not a good place to start. One last question: will cross-core communications channels be allowed? > Gernot Sincerely, Demi
OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
