On the Genode Book

I like the way they begin as they describe where OS’s are found. I would add that the OS is somewhat like a police function that makes each of the several functions of the device survive on the merits of the code directly and indirectly supporting that function, without relying on the merits of other code in the device. (Actually no, We get there only for capability systems.)

Quote:

SeL4 does not dynamically assign objects to DRAM. Particular DRAM is allocated to an object for its lifetime. In short seL4 does not swap. This would have been wildly impractical for Keykos in its time and as the paragraph above suggests, too expensive for many purposes today. VM/370 was an early virtual machine host which delivered virtual machines with few object attributes. VM/370 swapped.

Quote:

That is in interesting description of the TCB. There is the issue of programs that are not programmed to “violate the interests of the user” but:

In their figure 1 I presume that the small squares denote pieces of code. At least most readers will take it that way. Apple seems to have thought that way as they incorporated pieces of Mach. That interpretation explains the inclusion in the red area of a box that is not in the direct call chain of the box at the top of the red area. The point is that some piece of code may be vulnerable to malformed calls from some of its clients to cause it to abuse its authority. Yet that does not impact the security of other users of that code. The reason is that there is one code body but two objects that obey that code and the corrupted object lacks the authority to damage the other object. Some code bodies, or behaviors, by their charter, need not be shared among mutually suspicious users. They need not survive malicious calls. Other behavior, by its charter, must distinguish its callers since what one caller says effects how it responds to another caller — shared abstracted state between mutually suspicious users.

Quote:

This is a common Keykos pattern but it is not enforced. The kernel is aware of no hierarchy but only who has what caps. It takes space and time to do something and unless someone gave you a bank cap for space and meter cap for time you won’t do much of anything. Calls to create something invariably(?) include capabilities to a bank and a meter.

These last two points may be related. When two objects obey the same code for customers of diverse interests, they should be incommunicado and consume space and time from their customer’s resources. You need flexible concepts of space and time via caps to achieve this, I think.

Page 12 lists four desirable characteristics of a system and suggests that Genode is the first to embrace them all. I think that Keykos and Coyotos embraced all of those earlier.

The following is based on an incomplete view of Genode. I write it here and now lest I forget. Apple, as best I can tell, devotes just one object to a behavior and this object is shared between all who need that behavior. Contagion!! If the b-tree directory object has a flaw that corrupts when some particular call is made on it, other customers are effected. Indeed the shared object has shared state that can be scrambled upon corruption. When implemented as in Keykos, a user can rely on the object as long as he does not perform this particular bad call. The is no state scrambling for there is no object where state from two clients exists. One client may corrupt its object but that cannot effect a sibling object for lack of authority. This is a weakness of Mac OS, as far as I can tell. I may be wrong about Genode in which case I will excise this text to another file.

Quote:

It is not as bad perhaps as I thought. I think the following must be the common practice. The space where the state of an unshared object lives must come from whoever the object serves, and the served has neither read nor write access to that space.

Quote:

Genode has division lines in place that I had not dreamt of. Genode can in some sense run on a variety of kernels. Running on top of Linux is a convenient debugging scenario. They enumerate some extant kernels that I did not know of. Known platforms:
Linux
ambient
nova
NOVA microhypervisor
hw
(Ordinary NOVA has Linux between Genode and real hardware.)
seL4:
(still experimental)
foc:
Fiasco.OC
okl4:
Originally from Open-Kernel-Labs
pistachio:
L4ka from Karlsruhe
fiasco:
Technische Universität Dresden
This is sort of the converse of the VR for legacy apps that I describe.

Quote:

I would add that each component has its own invariants clearly separated from the other. There may be invariants that relate the states of these two components, but those should be written respecting the abstractions in place.

Quote:

I fear the impression that any function may be called. In Keykos the domain is the entity known to the scheduler and there cannot be ‘two threads’ in a domain for the Keykos domain is the closest thing to a thread in Keykos. The code that the domain obeys has exclusive access to the state of the object defined by the domain. I also fear that the caller is supposed to know the spelling of the name of the function. This description might lead the reader to imagine that for any user mode mode code that there are messages that it cannot process.

On the other hand it does nail down some important notions from the language theory perspective.

Quote:

The word “delegation” leaves the connotation that the protection that sends the cap has a superior status to the domain that receives the cap, and the kernel is supposed to recall this after the transfer is done. In Keykos the relation between the two domains with a cap to the object, is symmetrical.

Quote:

A clear difference between Genode and Keykos. Keykos logic is: Another difference is that the kernel allocates space in the c-list, as Unix decides on new fd values. A creation call site in Keykos expects a new capability to be returned and says in the key invocation setup, where to put the new cap. This was in analogy to performing a multiply operation where the instruction names the register which is to receive the product.

Quote:

There seems to be just one thing here in Keykos, both conceptually and really.

Quote:

This sounds as if the capabilities are facets on an underlying object implemented by the Genode ‘protection domain’. This is welcome in this context. The map is:
Genodefacet
terminology
protection domainobject
RPC objectfacet

Figure 6 suggests to me that when a protection domain receives a new cap as it is called, the kernel looks to see if the domain already holds that cap. I think this may reveal things that some would object to. I shall think about it. If it is done efficiently it provides a form of synergy.

Page 46


More Genode notes