[EROS-Arch] Proposed new facility: reducing resume capabiliti es

[Karp, Alan]

Jonathan wrote:
>
> The original caller has already sent the information that would be 
> retransmitted, so there are no negative security implications. 
>
Whenever I see a sentence like this, the phrase "replay attack" comes to
mind.  I don't think it applies here, but I thought I'd check.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-3
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
  
-----Original Message-----
From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
Sent: Friday, September 21, 2001 7:18 AM
To: eros-arch@mail.eros-os.org
Subject: [EROS-Arch] Proposed new facility: reducing resume capabilities


The proposal is that there should be some mechanism -- probably a new kernel
capability -- by which to convert a resume capability into a fault
capability to the same process.
 
This mechanism would allow a service to induce an invoker to retry an
invocation. This is usually innocuous, but combines with POST events in an
interesting and useful way.
 
Relevant Detail:
 
In the EROS invocation protocol, the invoker PC is not advanced until the
subsequent *inbound* invocation.  When a CALL is performed, the PC is not
advanced until the generated resume key is invoked. When a RETURN is
performed, the PC is not advanced until some start key is invoked.
 
By enabling a service to return to a fault key instead of the intended
RETURN key, the server can induce the invoker to retry the invocation.
 
Security Implications:
 
The original caller has already sent the information that would be
retransmitted, so there are no negative security implications. The effect
from the server side can be simulated by performing a RETURN operation on
the same server start key originally invoked by the original caller, passing
the arguments supplied by the original caller.
 
There is a slight exposure if a caller-side debugger has tweaked things. I
don't see a problem with this, but perhaps someone else may?