[EROS-Arch] Proposed new facility: reducing resume capabilities
Jonathan S. Shapiro
shap@eros-os.org
Fri, 21 Sep 2001 10:17:35 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_0201_01C14286.A25A1CB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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?
------=_NextPart_000_0201_01C14286.A25A1CB0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>The proposal is that there should be =
some mechanism=20
-- probably a new kernel capability -- by which to convert a resume =
capability=20
into a fault capability to the same process.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This mechanism would allow a service to =
induce an=20
invoker to retry an invocation. This is usually innocuous, but combines =
with=20
POST events in an interesting and useful way.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Relevant Detail:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In the EROS invocation protocol, the =
invoker PC is=20
not advanced until the subsequent *inbound* invocation. When a =
CALL is=20
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=20
is invoked.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>By enabling a service to return to a =
fault key=20
instead of the intended RETURN key, the server can induce the invoker to =
retry=20
the invocation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Security Implications:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The original caller has already sent =
the=20
information that would be retransmitted, so there are no negative =
security=20
implications. The effect from the server side can be simulated by =
performing a=20
RETURN operation on the same server start key originally invoked by the =
original=20
caller, passing the arguments supplied by the original =
caller.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>There is a slight exposure if a =
caller-side=20
debugger has tweaked things. I don't see a problem with this, but =
perhaps=20
someone else may?</FONT></DIV></BODY></HTML>
------=_NextPart_000_0201_01C14286.A25A1CB0--