Subject: RE: [rohc] sigcomp issue sugar-3

From: "Price, Richard" <[email-masked]>
Date: Tue, 23 Apr 2002 17:30:36 +0100

> "Price, Richard" <[email-masked]> writes:
> 
> > The problem with overwriting the stack_location register is just that
> > the addresses of the 2-octet words stack_free and stack[n] depend on
> > the value contained in stack_location. So if stack_location is
> > overwritten then the behaviour of the PUSH, POP, CALL and RETURN
> > instructions may become unpredictable.
> 
> That would be fine, I believe.
> Do we have to define the precise outcome in all error situations?
> (Cf. DIVIDE by zero...)

My concern with not defining the outcome of all error situations is that
implementers may fail to spot that the error can occur, and as a result
they may fail to take adequate security protections against buffer
overflow attacks and so forth.

Moreover, the only reason that an error condition will occur is because
the bytecode has been messed up (either accidentally or maliciously). In
an unsecured environment it's probably wise to call a decompression failure
in this case (same goes for DIVIDE by zero).

> I we want to be predictable and safe, "overwritten in the course of
> PUSH, POP, CALL, RETURN" could be the cause for DECOMPRESSION_FAILURE.
> More code for the implementers (another memory cell to protect).
>
> > If we want to allow the stack to overwrite its own stack_location then
> > we need to define precisely how the above instructions function in this
> > situation: namely the point at which the addresses of stack_free and
> > stack[n] change to reflect the new value of stack_location.
> 
> Again, I would be happy with "unpredictable", but we actually could go
> ahead and define the "RTL" for these four instructions, i.e. the
> precise sequence of events.

Assuming that we want to store the stack in low memory, I'd be marginally
happier if we call a decompression failure when the stack overwrites its
own stack_location. However, any solution is fine provided that it isn't
along the lines of "crash horribly and corrupt the memory for the entire
endpoint"!

Regards,

Richard

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Wed, 24 Apr 2002 10:30:04 +0100

Hi all,

Throwing in a couple of points from an implementer...

> overflow attacks and so forth.

This is obviously a concern.  However, trying to circumscribe all error 
cases (other than by listing the complete set of all allowable UDVM 
programs ;-) can be long-winded.  (Both for the spec. and the program)

I understood that the intent was more to ensure that the VM ran in a 
*very* constrained 'sandbox' with extremely limited interface to the 
outside world (and tight bounds on how much resources it is allowed to 
consume).

Provided that implementers nail these key aspects down, anything else is 
just an optimisation..?  It's keeping the interface simple & 
well-defined that helps.

> in this case (same goes for DIVIDE by zero).

This is obviously sensible.  However, provided that 'undefined' can 
include 'decompression failure', then it is allowable for a UDVM to 
react in this way.  (So do we need to mandate it..?  In all cases..?)

>>More code for the implementers (another memory cell to protect).

Avoiding code sounds good...

> along the lines of "crash horribly and corrupt the memory for the entire

This, I guess, is what I meant about the sandbox thing -- I don't think 
that it should be possible for the UDVM to access the memory in the 
endpoint, other than through the well-defined instruction interfaces. 
If it wants to trash the VM stack, that's fine (well, you know what I mean!)

An implementation may be considered 'better' if it stops promptly on 
detection of weird stuff happenning, but it shouldn't matter, particularly.

> Richard

Cheers,

Mark.

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Apr 2002 17:50:26 +0200

> in this case (same goes for DIVIDE by zero).

Having thought more about this, DIVIDE (or REMAINDER) by zero is a 
condition that an implementation already has to check for on many 
architectures (to avoid crashing and burning themselves), so I have 
added text that makes this a DECOMPRESSION-FAILURE.

> along the lines of "crash horribly and corrupt the memory for the entire

Based on Mark's message today, I propose the new text I just checked in, 
which makes the behavior in this case unpredictable (and encourages 
DECOMPRESSION-FAILURE in a "checking" implementation).  It also defines 
the stack in (I hope) a slightly more rigorous manner.

Comments?

I'd like to move this to "Resolution proposed in current editors' 
working document".

Gruesse, Carsten

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc