Model Permission on Hold Edges

[sid-agrawal]

This should help with comments about the difference between the code–page held by the PD and the same code page held by the kernel. Process-PD has R perms to the code page, and the kernel has map perms to the process code page.

We can also use this to capture whether the memory in the resource is interprested by the PD or not.

Notion of “interpreted” vs “non-interpreted” resources accesses. This is of interest when we talk about the fault radius. If a resource that can be written by PD1 that is being interpreted by another PD2, then a failure of PD1 may result in corruption of that resource and thus can lead to a crash in PD2 when it tries to interpret this. If it is non-interpreted then this is not an issue, e.g., an encryption service will happily encrypt the resource regardless of whether its data makes sense or not. Similarly, there seems to be a notion of the contents of a resource, vs. the address of a resource. The address of encrypted memory may be read but its contents not deciphered – with writing that would be another story. I think that may be expressible using permissions on hold edges.

[sid-agrawal]

It is more clear from [1,2] that we need to consider PDs as resources, too. Then, an edge from PD(active) to PD (as a resource) would have take & grant permissions.

This relates to our conversation about execution context, as it seems like a PD is just a way to enforce resource constraints, not really an active entity.

• 39

Further, if the PD is backed by some memory, then it has a map edge to memory, and the EC (or PD, I'm not sure) holding that memory enforces this PD abstraction. This relates to

• 40

[1] Protection: https://dl.acm.org/doi/10.1145/775265.775268 [2] Hierarchical Take-Grant Protection systems: https://dl.acm.org/doi/abs/10.1145/1067627.806598