www.digitalmars.com         C & C++   DMDScript  

D - D memory space assumptions ?

reply Mike Wynn <mike l8night.co.uk> writes:
Walter,

what assumptions does the D compiler make about the memory space ?
I assume currently it is
A) flat 32 bit
B) on x86 CS, DS, ES and SS if not the same map to the same address 
space cs:[0] == ds:[0] == es[0] == ss:[0]
C) no support for "far" (with segment) or just longer than usual pointers.
D) threads can see each other stacks.
E) code is readable (and consts are in code)

from an application programmers point of view that is great, I have been 
thinking of trying to use the protection the x86 offers to do the following.
cs: code seg (exe only)
ds: data seg (read/write no execute)
es: const seg (read only)
ss: stack seg (read/write) only current thread can see it.

but each would be 0 based so pointers to automatics would not be 
passable as params (solveable if stack structs/arrays could be forced 
into the heap). (inout/out know that its an ss not ds based offset)

although I'm rapidly comming to the conclusion that x86 segments are 
pointless (I want to create a protected range).

do you intend to add support for "far" calls or calls into a different 
"space" (and ways to declare that a function is in a specific "space"), 
for instance on Arm7T/Arm9T you have two instruction sets ARM and Thumb, 
the compiler would need to know which instruction set has been used to 
get the address correct (thumb has bit 0 set).

do you intend to support named "segments" to allow data/code to be put 
into different places.
allowing statics to be allocated in name segments (on linux/win32 they 
would just be sorted together then put into data/bss as requires)
named segments either data (0's stored in image if not initialised) or 
bss (initialisers not allowed) or const (rom/code).
not all arch's have contigious address spaces and some have fast/slow 
ram/rom areas so placement can be important.
Sep 09 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bjl7a8$2a2n$1 digitaldaemon.com...
 Walter,

 what assumptions does the D compiler make about the memory space ?
 I assume currently it is
 A) flat 32 bit
 B) on x86 CS, DS, ES and SS if not the same map to the same address
 space cs:[0] == ds:[0] == es[0] == ss:[0]
 C) no support for "far" (with segment) or just longer than usual pointers.
 D) threads can see each other stacks.
 E) code is readable (and consts are in code)

The short answer is exactly the same assumptions that the associated C compiler makes - DMC for Win32, and gcc for Linux. A..E are true, except that consts go into the data segment, not code segment.
 from an application programmers point of view that is great, I have been
 thinking of trying to use the protection the x86 offers to do the

 cs: code seg (exe only)
 ds: data seg (read/write no execute)
 es: const seg (read only)
 ss: stack seg (read/write) only current thread can see it.

 but each would be 0 based so pointers to automatics would not be
 passable as params (solveable if stack structs/arrays could be forced
 into the heap). (inout/out know that its an ss not ds based offset)

 although I'm rapidly comming to the conclusion that x86 segments are
 pointless (I want to create a protected range).

I don't really understand why Win32 doesn't turn off the "execute" bit for the stack. That would put the kibosh on most buffer overflow exploits.
 do you intend to add support for "far" calls or calls into a different
 "space" (and ways to declare that a function is in a specific "space"),
 for instance on Arm7T/Arm9T you have two instruction sets ARM and Thumb,
 the compiler would need to know which instruction set has been used to
 get the address correct (thumb has bit 0 set).

No. I left all that far call stuff back in the dos world <g>.
 do you intend to support named "segments" to allow data/code to be put
 into different places.
 allowing statics to be allocated in name segments (on linux/win32 they
 would just be sorted together then put into data/bss as requires)
 named segments either data (0's stored in image if not initialised) or
 bss (initialisers not allowed) or const (rom/code).
 not all arch's have contigious address spaces and some have fast/slow
 ram/rom areas so placement can be important.

At the moment, not any more than you can with C compilers.
Sep 09 2003
next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 "Mike Wynn" <mike l8night.co.uk> wrote in message
 news:bjl7a8$2a2n$1 digitaldaemon.com...
 
do you intend to add support for "far" calls or calls into a different
"space" (and ways to declare that a function is in a specific "space"),
for instance on Arm7T/Arm9T you have two instruction sets ARM and Thumb,
the compiler would need to know which instruction set has been used to
get the address correct (thumb has bit 0 set).

No. I left all that far call stuff back in the dos world <g>.

so no 48 bit far calls ?
 
 
do you intend to support named "segments" to allow data/code to be put
into different places.
allowing statics to be allocated in name segments (on linux/win32 they
would just be sorted together then put into data/bss as requires)
named segments either data (0's stored in image if not initialised) or
bss (initialisers not allowed) or const (rom/code).
not all arch's have contigious address spaces and some have fast/slow
ram/rom areas so placement can be important.

At the moment, not any more than you can with C compilers.

on gcc you have __attribute__((section("foo"))) how do I do that in D ?
Sep 09 2003
parent "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bjlnh0$3111$1 digitaldaemon.com...
 Walter wrote:
 "Mike Wynn" <mike l8night.co.uk> wrote in message
 news:bjl7a8$2a2n$1 digitaldaemon.com...
do you intend to add support for "far" calls or calls into a different
"space" (and ways to declare that a function is in a specific "space"),
for instance on Arm7T/Arm9T you have two instruction sets ARM and Thumb,
the compiler would need to know which instruction set has been used to
get the address correct (thumb has bit 0 set).



Right. You'd have to do a shim for them in assembly.
 At the moment, not any more than you can with C compilers.


At the moment, run patchobj.
Sep 09 2003
prev sibling parent reply "Serge K" <skarebo programmer.net> writes:
 I don't really understand why Win32 doesn't turn off the "execute" bit for
 the stack. That would put the kibosh on most buffer overflow exploits.

The tricks with stack works by overwriting return address, but this address is still for the location in the CS segment - disabling code execution for it is not a good idea... ;-) IA32 has an "execute" bit for segments only, there is no way to control it per page.
Sep 10 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Serge K" <skarebo programmer.net> wrote in message
news:bjotnm$1cn8$1 digitaldaemon.com...
 I don't really understand why Win32 doesn't turn off the "execute" bit


 the stack. That would put the kibosh on most buffer overflow exploits.


 is still for the location in the CS segment - disabling code execution for
 it is not a good idea... ;-)
 IA32 has an "execute" bit for segments only, there is no way to control it
 per page.

The way to do it is to not have the CS segment contain the stack area. It is possible to have CS and SS have different selectors mapping over each other, but with different sizes.
Sep 10 2003
parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 "Serge K" <skarebo programmer.net> wrote in message
 news:bjotnm$1cn8$1 digitaldaemon.com...
 
I don't really understand why Win32 doesn't turn off the "execute" bit


for
the stack. That would put the kibosh on most buffer overflow exploits.

The tricks with stack works by overwriting return address, but this

address
is still for the location in the CS segment - disabling code execution for
it is not a good idea... ;-)
IA32 has an "execute" bit for segments only, there is no way to control it
per page.

The way to do it is to not have the CS segment contain the stack area. It is possible to have CS and SS have different selectors mapping over each other, but with different sizes.

D/C/C++ make the assumption that the address of a stack object is in the "data segment" and that two threads can see each others stacks. so you can not gain any benifit from SS it has to be DS because the x86 segmenting only allow 0..n to remap to m..(n+m) not a...b to map to a+m..b+m also it is allowable for threads to write in each others stacks auto int a[10]; you can pass &a[n] to another thread. it is true that not having the stack or data space visible via the cs would solve the problem where the return address is overwritten to branch into code that has been layed onto the stack (usual buffer overrun method), it does not stop you launching the eip into hyperspace, or jumping back N functions with a valid return value thus avoiding some check or other (patch rtn+oldebp) is done right you jump back to a leave rtn so both esp and ebp can be set to whatevery you like. solution is to only use the hardware stack for rtn address (maybe save/restore of registers) and use ebx instead of esp thus you can have a stack in the heap.
Sep 11 2003