At 16:00 -0400 8/23/99, shapj@us.ibm.com wrote:
>I am struck by the possibility that if Rees's SEAL operation accepted a unique
>object pointer (cons cell would be fine) as an argument, and if the
>corresponding UNSEAL demanded presentation of the same cons cell pointer, that
>the operation itself would need to be implemented in privileged code but the
>sealing tool would not need to be defended from general use.
I believe that both statments are true. Rees made the same sort of argument for the benevolence of seal and unseal. I had intended to make that point myself. Thanks.
>We had a parallel
>discussion about this in context of the process tool, and concluded at
>that time
>that the process tool itself did not require protection.
What we called the domain tool was somewhat restricted. Once I wrote a program that intermediated keys just as a would a program that exported capabilities over a network. The system crashed when it tried to intermediate the domain tool, which I had not realised was accessible to the program that I was testing. I recall realizing what had gone wrong and that it was a fixable bug in the 370 kernel. I think that the bug was not fixed and I don't remember what the problem was now. I recall that it was evident in the crash.
I do not know of any reason to restrict the domain tool once the kernel is
fixed.
(well actually there are four domain states if holders of the domain tool
misbehave. You can have a restart key to a running domain. I 370 kernel is
designed to tolerate this.)
None of these problems reflected on the safety of general access to a
seal-unseal primitive. They had all to do with other special magic of
domains.
Norman Hardy <http://www.mediacity.com/~norm>