Subject: RE: [rohc] operator "!" in the udvmassembly (draft-ietf-rohc-sigcomp-user-guide-01.txt)

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 1 Jun 2005 16:27:20 +0200

Something that should be addressed in the implementer's guide?

/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Adam Roach
> Sent: den 1 juni 2005 16:18
> To: Carsten Bormann
> Cc: [email-masked]
> Subject: Re: [rohc] operator "!" in the udvmassembly
> (draft-ietf-rohc-sigcomp-user-guide-01.txt)
> 
> 
> Carsten Bormann wrote:
> 
> > Hi Cristian,
> >
> > On May 30 2005, at 13:27 Uhr, Cristian CONSTANTIN wrote:
> >
> >> is there any technique for an udvm assembler
> >> to detect (at "assemble time") the closest zero byte
> >> to a given address so that this byte is really going to be a
> >> DECOMPRESSION-FAILURE instruction at run time and NOT some 
> data that
> >> is supposed to be loaded with some other value or some 
> self-modifying
> >> instruction?
> >>
> >> (I'm taking into account here the peculiarities of the 
> udvm code: mixed
> >> data and code, self-modifying code)
> >
> >
> > Good point.
> > No, we did not consider self-modifying code when we defined "!".
> >
> > Maybe a real-world assembler needs some additional hints here.
> >
> > Strawman: How about a new set of directives to identify 
> read-only and 
> > read-write sections?
> 
> 
> I think I would prefer to leave it as-is, with a caveat that 
> writers of 
> self-modifying code need to be aware of possible interactions 
> with the 
> use of "!".
> 
> /a
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jun 2005 10:36:49 +0200

> Something that should be addressed in the implementer's guide?

Actually, this is a fix to the assembly language, which is described in 
the user's guide; the change would go into the description of "!" at 
the end of 3.2.1 as well as into one/two new directives to toggle r/o 
with r/w.

Strawman again:
ro
INPUT-BYTES(...)
rw
:scratchpad

Default should be rw (which unfortunately means all existing UDVM 
assembly code with "!" in it won't assemble until some ro directives 
are inserted).

A debugging implementation of the assembler could save the ro/rw bits 
per byte somewhere for a debugging implementation of the UDVM to do the 
equivalent of segfaulting when an ro byte is changed.

So far, all directives have parameters, so alternatively the syntax 
could be something like:

ro(1)
ro(0)

or maybe

code
data
(but then, there is read-only data.)

(Oh, s/black/blank/ on page 6 -- Abbie, did you do this to test the 
attention of the readers? :-)

Gruesse, Carsten

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 29 Jun 2005 12:01:02 +0200

> (but then, there is read-only data.)

cristian: I think that having these directives in the assembly language
is the only 100% correct solution; the most elegant too...

on the other hand is there any possibility of having these kind of
pledges (or call them hints) at run time (i.e for the interpreter)?
what I mean here, is to have some kind of attributes for the blocks of
udvm memory: ro, rw, exec; for example a jmp into a non-exec block
should cause a decompression failure and the same for any kind of write
into a ro block. knowing exactly, for example, that certain code blocks
are ro and that certain rw blocks are non-executable would help with the
dynamic translation...

waiting for your answer.
cristian
-- 
 _          | There are many people who use UNIX or Linux  
(_'_        | who IMHO do not understand UNIX.
  (_'rist   |              --David Korn  
GPG public key at wwwkeys.de.pgp.net
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Jun 2005 08:47:33 -0500

>are ro and that certain rw blocks are non-executable would help with the

The first several drafts of the UDVM specification included an opcode, 
called "WORKING-MEMORY", which served exactly this purpose -- it marked 
sections of memory as being read-only. Attempts to write to these blocks 
resulted in decompression failures. (cf. draft-ietf-rohc-udvm-00.txt)

This functionality was removed in February of 2002 (between 
draft-ietf-rohc-sigcomp-04.txt and draft-ietf-rohc-sigcomp-05.txt), 
although I can't remember the exact reasons why. I assume that Richard 
or Carsten can fill us in on the details.

Unfortunately, the ship has already set sail on this issue; it's not 
something you can reverse without revving the whole SigComp virtual 
machine again. Changing the assembly language is still a reasonable 
option; changing the behavior of the bytecodes is not.

/a

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jun 2005 16:15:47 +0200

> Unfortunately, the ship has already set sail on this issue;

Marking memory as r/o vs. r/w on the wire protocol would be 
counterproductive to the compression efficiency.
However, nobody stops you from having a "debug mode" in your UDVM, 
where you use an r/o vs. r/w map to catch misbehavior early.
The way this map gets to the UDVM would be outside the scope of 3320 
(e.g., it could arrive via an oracle).
This would be another use of the ro/rw nomenclature that I have 
proposed for the assembly language to enable "!".
(And yes, it should be some form of op(value) for consistency with the 
other directives.)

Gruesse, Carsten

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 29 Jun 2005 18:32:46 +0200

> where you use an r/o vs. r/w map to catch misbehavior early.

cristian: I'm not interested into debugging here... I'm interested into 
translating dynamically (i.e. at "interpret time") the udvm bytecode to
native machine code (x86,sparc, powerpc, etc). 
it can be done for the current specification as well. having 'a priori' 
extra information about blocks in the udvm memory would help, though.

thanks for the details, anyway...
bye now!
cristian