[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    Re: [EROS-Arch] Proposed new facility: reducing resume
From:       Bill Frantz <frantz () pwpconsult ! com>
Date:       2001-09-22 1:12:43
[Download RAW message or body]

At 1:18 PM -0700 9/21/01, Jonathan S. Shapiro wrote:
>> Any of the keys invoked or passed in the jump could become [void] keys
>which
>> means that the second try would not be the same as the first.  Any user of
>> this mechanism would be well advised to make no changes in state as a
>> result of the first try.  This is classic "dry run" programming.
>>
>> Change the invoked key resulting in the information going to a different
>> domain.
>>
>> Change the keys/data passed in the jump.
>
>I agree with all of these statements. In the event that the transmitted keys
>have been voided, the server already holds voided keys from the first
>invocation; I see no security issue here.

I agree.  I was trying to cover the cases.

>In the event that the keeper changes the transmit keys, this is in some
>sense a voluntary new transmission -- not a security issue, but definitely a
>potential caution to server writers. I don't know that this is different
>from a similar, completely new invocation that transmits different
>arguments.

I doubt that most servers could tell the difference.

>The only way the invoked key can be voided is if the server itself has been
>rescinded. This seems unlikely, but might occur in the A calls B forwards to
>C issues retry case.

In this case, the service does not get invoked again.  Service writers beware.
>
>In any case, all of these cases are triggered at the volition of the
>service, because the service is ultimately in control of whether a requested
>retry occurs. Further, all of these can already be induced using the keeper
>tricks I mentioned previously.
>
>> Since the PC has not advanced, the domain key holder sees the view that
>the
>> jump has not yet occurred, and should be suitably warned.
>
>Mumble. Yes. I was trying (and failing) to remember why the decision of when
>to advance the PC was important.
>
>But this seems easily detected. If the instruction has been initiated then
>the invoker is in the available or waiting state, not the running state. In
>either case it can be assumed that it is in mid-invocation. Whether the PC
>moves early or late you have the same problem; the only change is which
>instruction we are asking the question about. Am I missing something?

I don't think so.  In KeyKOS we tried to keep a domain key holder from
knowing whether the domain was running, stalled, or waiting.


Note that there were many times in KeyKOS where I wanted a facility similar
to this.  It was so easy to do in the kernel, and so hard to do with
domains.

There is a warning for people writing domains that pass the resume key they
received.  These domains may be invoked several times for what the caller
thinks is one invocation, at the discretion of the domains they pass resume
keys to.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz@pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA


_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch

[prev in list] [next in list] [prev in thread] [next in thread]