From: Godmar Back (gback@cs.utah.edu)
Date: Mon Feb 08 1999 - 16:14:20 EST
>
> :>
> :> I don't understand your statement about
> :> "But once you've executed something in it you cannot write to it again."
> :> Of course you can write into it and execute it again.
> :>
> :
> :I just realized that saying "you can write into it and execute it again"
> :does not refute your statement.
> :
> :What I mean is that you can write to the data segment and execute code
> :in it arbitrarily.
> :
> : - Godmar
>
> Most modern processors have a separate instruction cache. Typically,
> writes to memory are only cached in the data cache, not the instruction
> cache. Thus if you have executed a piece of code ( causing it to be
> brought into the instruction cache ), and then attempt to change
> that code by writing to the memory where said code resides, then execute
> it again, the processor may execute stale instructions from the
> instruction cache instead of the new instructions you wrote into the
> memory.
>
> So, the rule of thumb is: You can write instructions to newly allocated
> memory but once you've executed them, you can't modify that memory.
>
That may be a rule of thumb, but current practice is what I explained in
an earlier mail: on systems that have a separate and independent instruction
and data caches (aka Harvard architecture), applications that create code
in memory have to flush the data cache before invoking the code. On the
Sparc, for instance, this is accomplished by using the "iflush" instruction.
It is not and never has been a problem on the x86 architecture.
You can argue that applications should use mmap and mprotect to ensure
that they have execution permissions for the memory to which they write
jitted code. Fine, but the reality is that there's so much existing code
out there that doesn't, and this is why I agree with your earlier judgement
to leave things the way they've always been.
I'm not saying that nothing speaks in favor of turning the x bit off:
for instance, turning the x bit off for your stack segment can help
avoiding stack buffer overrun attacks, and a similar argument can be
made for the data segment.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:02 EDT