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

From: Adam Roach <[email-masked]>
Date: Wed, 01 Jun 2005 09:17:34 -0500

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

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Sun, 5 Jun 2005 00:27:38 +0200

> self-modifying code need to be aware of possible interactions with the 

cristian: hi. once again, in my oppion, using "the closest zero byte" address 
as the address by which the "!"-operator is replaced conflicts with two 
peculiarities of the udvm architecture:

1. mixed data and code (i.e no separate code and data "segments"). "the
closest zero byte" address may lie somewhere in your data at "assemble
time" (that is when you generate your bytecode); but at run time when
you do the jump the data may have changed because some other instruction
has overwritten it with something. here again it's tricky bec. that
something may make sense as an instruction (just by chance) or may not.
if it makes sense as an instruction and it gets executed because of the
"!" jmp, your program transforms itself in somenthing you did not
intend; otherwise you probably get your DECOMPRESSION-FAILURE, but again
not as intended.
I have tried to illustrate my point with a highly nonsensical 
(dummy and naive) example. if you have time please have a look at the
attachment files (data_!.udvm, data_!.bytecode - represented
like space separated hex bytes, first column the address, again in hex,
set your entry point to 0x44 if you try to run it)

2. self-modifying code. "the closest zero byte" address may be, for
example, the address of an operator of an instruction, which at 
assemble time is zero. but at run time the instruction and its operator 
might have been changed by some other instruction. 

I cannot help myself from the following comment :-) 
I have to say that I don't know if I have used the
right term when I have said "self-modifying code".
what is code and what is data??
is it any distinction? for example at run time, at one moment of time
one can do a control flow analysis and find all reachable (executable) 
blocks of code starting from the current instruction; that would make the
distinction btw. your code (what gets to be executed) and your data
(chunk of memory that doesn't get to be executed). 
but the very next instruction can change that by overwriting a piece of
code; and what used to be data becomes code and the other way around :-) 
I have used the term "self-modifying code" because it has seemed
to me the most appropriate.

bye now!
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: Carsten Bormann <[email-masked]>
Date: Sun, 5 Jun 2005 10:13:18 +0200

On Jun 01 2005, at 16:17 Uhr, Adam Roach wrote:

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

As Cristian's example pointed out, the closest zero byte may actually 
be data that will be overwritten.
One heuristic would be to consider all instructions read-only and all 
other space read-write unless specified otherwise by a directive.
I'd rather have that directive, though, to be able to make my 
intentions as a UDVM coder explicit.
(For those who came late: all of this discussion is "off the wire", at 
the assembly time; there is no problem with RFC3320 proper.)

Gruesse, Carsten

---

From: Adam Roach <[email-masked]>
Date: Sun, 05 Jun 2005 22:14:13 -0500

> be data that will be overwritten.

Hmmm... when I implemented this, I never even considered using a data 
byte as "the closest zero byte." If there's not a zero in the code 
(which hasn't happened so far), my compiler simply inserts one.

> other space read-write...

(Which is effectively what I've implemented)

> ...unless specified otherwise by a directive. I'd rather have that 
> directive, though, to be able to make my intentions as a UDVM coder 
> explicit.

Okay, I can buy that this kind of directive would be useful. I far 
prefer the directive-with-parameter approach, as anything else would 
require some ungainly changes to the syntax parsing state machine.

/a