[EROS-Arch] number key endianness

[Karp, Alan]

Well, with e-speak we may be going over the network or not, but we don't
want the client or service to know the difference.  Hence, we added a level
of indirection that I think may be appropriate, at least for E if not for
Eros.  The point is that an invocation may be one-shot for a particular
client, but the connection between machines is often long-lasting.  If you
envision a world where a connection between machines, even emulated ones, is
established on each invocation, read no farther.

In e-speak Beta 2.2, when two machines wanted to connect, they each started
a proxy to act on behalf of the other machine.  (One proxy could be use for
more than one connection, but that's only an optimization.)  Each proxy had
only those capabilities available to users on the other machine.  Thus, even
if an attacker got the proxy to execute an arbitrary piece of code, the
proxy couldn't do anything that a user on that machine couldn't do.  Even a
DoS attack would most likely only crash the proxy, cutting off the attacker.

The proxies did the connection negotiation, including authentication of the
other machine, communication parameters such as endianness, and deciding
whether or not to encrypt on the link.  Once that was done, any client on
one machine could invoke any service on the other without worrying about the
invocation being remote.  You'll note that with this configuration, only the
proxies knew there's another machine in the world.

We used another trick here.  Since we controlled the protocol, messages were
objects serialized down to base types, such as integer and character.  Each
time a base type appeared in the message, it was preceded by a signal byte
denoting its type.  With this feature, the proxy could do any translation
needed over the wire.  

This approach doesn't work for encrypted payloads.  We recommended two
options.  Either the endianness became part of the service interface, as you
propose, or the 4 bytes defining the parameters were put at the start of the
message.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
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@cs.jhu.edu]
> Sent: Thursday, March 01, 2001 3:28 PM
> To: Karp, Alan
> Cc: 'clandau@macslab.com'; eros-arch@eros-os.org
> Subject: Re: [EROS-Arch] number key endianness
> 
> 
> "Karp, Alan" wrote:
> > 
> > The first message sent by the Initiator was 4 bytes that 
> encoded its byte
> > order, integer length, and character encoding.  (I only 
> needed 8 bits, but I
> > left room for growth.)  The first reply from the Listener 
> was its 4 bytes.
> > The rule was "Initiator makes right".
> 
> This makes sense for a connectionful protocol, but capability
> invocations are frequently one shot, so a startup protocol 
> adds too much
> overhead. I think we will have to design that service specifies byte
> order and client makes right. Note that we aren't going over networks
> with this stuff -- it's only a consideration on machines that emulate
> multiple architectures.
> 
> Jonathan
> _______________________________________________
> eros-arch mailing list
> eros-arch@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/eros-arch
>