27 Nov
2017
27 Nov
'17
5:11 p.m.
From: Doug McIlroy
But if that had been in D space, it couldn't have
been executed.
Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.
Programs which emit these little 'custom code fragments' (I prefer that term,
since they aren't really 'self-modifying code' - which I define as 'a
program
which _changes_ _existing_ instructions) must have some way of having a chunk
of memory into which they can write, but which can also be executed.
Where is the boundary between changing one instruction
and changing them
all? Or is this boundary a figment of imagination?
Well, the exec() call only overwrites existing instruction memory because of
the semantics of process address space in Unix - there's only one, so it has
to be over-written. An OS operating in a large segmented single-level memory
could implement an exec() as a jump....
BTW, note that although exec() in a single address-space OS is conventionally
something the OS does, this functionality _could_ be moved into the user
space, provided the right address space primitives were provided by the OS,
e.g. 'expand instruction space'. So the exec() code in user space would i)
find the executable, ii) see how much of each kind of memory it needs, iii)
get the OS to give it a block of memory/address space where the exec() code
can live while it's reading in the new code, iv) move itself there, v) use
standard read() calls to read the new image in, and then vi) jump to it.
Yes, it's probably simpler to implement it in the OS, but if one's goal is to
minimize the functionality in the kernel...
Noel
27 Nov
27 Nov
5:50 p.m.
New subject: Harvard and Von Neumann Architectures and Unix
On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
Isn't that how dtrace works?
From: Doug
McIlroy
But if that had been in D space, it couldn't
have been executed.
Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.
Programs which emit these little 'custom code fragments' (I prefer that term,
since they aren't really 'self-modifying code' - which I define as 'a
program
which _changes_ _existing_ instructions) must have some way of having a chunk
of memory into which they can write, but which can also be executed. 
6:08 p.m.
New subject: Harvard and Von Neumann Architectures and Unix
SPICE2 does the same sort of thing (in semi-portable Fortran-IV)
On Mon, Nov 27, 2017 at 11:50 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa
wrote:
term,
From:
Doug McIlroy
But if that had been in D space, it couldn't
have been executed.
Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.
Programs which emit these little 'custom code fragments' (I prefer that since they aren't really
'self-modifying code' - which I define as 'a
program
which _changes_ _existing_ instructions) must
have some way of having a
chunk
of memory into which they can write, but which
can also be executed.
Isn't that how dtrace works?
7:21 p.m.
New subject: Harvard and Von Neumann Architectures and Unix
On 2017, Nov 27, at 12:08 PM, Clem Cole
<clemc(a)ccc.com> wrote:
SPICE2 does the same sort of thing (in semi-portable Fortran-IV)
On Mon, Nov 27, 2017 at 11:50 AM, Larry McVoy <lm(a)mcvoy.com
<mailto:lm@mcvoy.com>> wrote:
On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
Isn't that how dtrace works?
In POSIX systems, the mprotect(2) syscall can set execute permissions.
From:
Doug McIlroy
But if that had been in D space, it couldn't
have been executed.
Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.
Programs which emit these little 'custom code fragments' (I prefer that term,
since they aren't really 'self-modifying code' - which I define as 'a
program
which _changes_ _existing_ instructions) must have some way of having a chunk
of memory into which they can write, but which can also be executed. 
7:30 p.m.
New subject: Harvard and Von Neumann Architectures and Unix
Lawrence Stewart wrote:
Noel Chiappa wrote:
Or if a statically allocated space is ok, just set your pages to rwx in
the executable image file.
Programs which emit these little 'custom
code fragments' (I prefer
that term, since they aren't really 'self-modifying code' - which I
define as 'a program which _changes_ _existing_ instructions) must
have some way of having a chunk of memory into which they can write,
but which can also be executed.
In POSIX systems, the mprotect(2) syscall can set execute permissions. 
7:14 p.m.
New subject: Harvard and Von Neumann Architectures and Unix
On Mon, Nov 27, 2017 at 9:50 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa
wrote:
term,
That's not self modifying code. I've written some self-modifying code (I
was young, it was sexy, I thought), and it's all about rewriting your own
instruction stream. And doing so based on data you get so far. Not every
modification of a text page is self-modifying code.
dtrace, and every debugger that doesn't have hardware assist debug
registers (or overflows them) modifies the text pages to allow breakpoints,
watchpoints, tracepoints and the like to work. Even the OS creates code to
run at runtime. The signal trampoline that's used to return from a signal
handler in BSD is a small bit of code the OS fills in bits of out of a
template. It's one of the things that slowed adoption of turning off the X
bit for stack pages in response to many of the buffer overflow attacks.
On modern architectures, a fair amount of PTE and/or cache dancing needs to
happen to make this stuff work sometimes. Some processors make this easy
with dual mappings, others are... what's the right word... tedious.
Warner
From:
Doug McIlroy
But if that had been in D space, it couldn't
have been executed.
Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.
Programs which emit these little 'custom code fragments' (I prefer that since they aren't really
'self-modifying code' - which I define as 'a
program
which _changes_ _existing_ instructions) must
have some way of having a
chunk
of memory into which they can write, but which
can also be executed.
Isn't that how dtrace works?
7:26 p.m.
New subject: Harvard and Von Neumann Architectures and Unix
On-chip, all modern x86 processors operate entirely out of a hierarchy
of caches, and there are separate caches for instructions and data.
Main memory is really merely the first in the "slow access storage"
hierarchy. So in that sense I suppose one could consider modern CPUs
to be Harvard architecture.
-Palu W.
6:35 p.m.
New subject: Harvard and Von Neumann Architectures and Unix
On 2017-11-27 11:11, Noel Chiappa wrote:
Programs which emit these little 'custom code
fragments' (I prefer
that term, since they aren't really 'self-modifying code' - which I
define as 'a program which _changes_ _existing_ instructions) must
have some way of having a chunk of memory into which they can write,
but which can also be executed.
As the writable/executable bits are usually in the page table (on linear
paged architectures which currently dominate the field), I imagine the
answer is dual page mappings.
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.
28 Nov
28 Nov
3:55 p.m.
New subject: Harvard and Von Neumann Architectures and Unix
On 27 Nov 2017, at 16:11, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.
Programs which emit these little 'custom code fragments' (I prefer that term,
since they aren't really 'self-modifying code' - which I define as 'a
program
which _changes_ _existing_ instructions) must have some way of having a chunk
of memory into which they can write, but which can also be executed.
I think, however this is done, it must be relatively tractable, because Lisp systems with
native-code compilers work fine on modern OSs, and they do very much more than generate
small code fragments.
--tim
8:45 p.m.
New subject: Harvard and Von Neumann Architectures and Unix
On 27 Nov 2017, at 16:11, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.
They do by default, at least, in that modern linkers create executable
images where the executable program segments are read-only and
read/write segments (including the stack) are not executable. But
modern OSes have system services for changing page protection, so an
application such as an interpreter or JIT can compose code and then
change the page protection to make it executable.
-Paul W.
2546
days inactive
2547
days old
9 comments
9 participants
participants (9)
-
Clem Cole -
Ian Zimmerman -
jnc＠mercury.lcs.mit.edu -
Larry McVoy -
Lars Brinkhoff -
Lawrence Stewart -
Paul Winalski -
Tim Bradshaw -
Warner Losh