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

From: "Price, Richard" <[email-masked]>
Date: Tue, 23 Apr 2002 13:31:09 +0100

> I think some of the confusion may stem from calling the stack pointer
> stack_free, when in reality we don't have a mechanism that checks
> there is enough space left on the stack (i.e. there are enough "free"
> locations on the stack).  Also, the notation stack[stack_free] is only
> defined by example, AFAICT.

Hi Carsten,

The terms stack_free and stack[n] are defined in Section 8.3, although
not in a particularly formal manner. If any of the terminology is
misleading or if a more formal definition would be useful then we can
easily update this section as needed.

> > The reason that stack_location is stored separately from
> > stack_free is that the former typically contains a fixed value
> > that will be retained between compressed messages, whereas the
> > latter contains a temporary value that will be reset to 0
> > before decompressing each message. Therefore, it is useful to
> > store stack_free together with the other temporary data (such
> > as the stack itself), outside of the memory area that will be
> > saved as state between compressed messages. I prefer this
> > mainly for "architectural reasons" as it keeps the temporary
> > and permanent areas of UDVM memory cleanly separated, but it
> > can also reduce the size of the uploaded bytecode as stack_free
> > does not have to be reset to 0 manually before decompressing
> > each message.
> 
> OK, I presume your point is that stack_free starts out at zero, so you
> can implicitly initialize it by allocating it in virgin UDVM core, in
> contrast to stack_location, which definitely needs to be initialized
> according to the decompressor's memory layout.

Precisely.

> > The value 56 is part of the following sentence:
> > 
> > "Decompression failure occurs if stack_free is ever decreased
> > below 0, or if one of the above instructions is encountered and
> > the value of stack_location is smaller than 56 (this prevents
> > the stack from overwriting the stack_location register)."
> > 
> > Address 56 is just the memory address immediately after the
> > stack_location register itself; we should probably rewrite the
> > above sentence to make this clear.
> 
> Why is it more important to protect the stack_location register than
> anything else?  In a resilient architecture, I'd imagine a stack_limit
> (or stack_size) register.  Now, we don't necessarily need that, but I
> still don't quite understand why my stack cannot start below 56 if I
> want it to.  Is it just to have a way to detect address wraparound?

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.

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.

> (Also note that "below 0" does not mean too much in an unsigned
> arithmetic setting.)

Ok, replace this with "if stack_free is ever decreased when it is
already 0" or something similar.

Regards,

Richard

---

From: [email-masked] (Dr. Carsten Bormann)
Date: 23 Apr 2002 15:05:24 +0200

> 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...)

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).

> 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.

Gruesse, Carsten

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