Re: Questions about Minix

Jo??o Jer??nimo <j_j_b_o_j@xxxxxxxxxxxxxxxxxxx> wrote:
J.F. de Smit wrote:
Perhaps not, but it would make stuff a lot easier to use (especially X,
allocating each component the memory it needs can be a real pain).

Yes. As I have read, Minix puts both the code and data segments in the same
chunck of memory. This real makes stuff very "static", because the stack
grows downwards, which means you couldn't just expand (and move arround if
necessary) the segment when the application demands more heap than was
initially expected (also, due to the sbrk system call spec, you can't just
split the data segment in two parts allocating the rest beyond the
stack)...

Your first statement isn't exactly correct and also doesn't seem related
to what you say next, but you got the majority of it right. Minix actually
_splits_ the code and data segments by default and assigns them different
segments. This has several consequences:

- address 0 (generally reserved for the NULL pointer) is actually a valid
address in the data segment, because the data segment contains only data
and no text. In situations where code and data share the same segment,
address 0 always contains code and should never be accessed (not even by
icky-icky self-modifying code). However, it is common sense to still
regard 0 as an invalid memory address because you need _something_ to
signal it and it costs you only 1 byte of usable memory

- remote code execution through stack overflow is a lot harder (if not
impossible) to accomplish, because the kernel forbids writing to a code
segment, and the CPU only fetches opcode from the code segment (and not
the data segment). Putting code on the stack and then overwriting a
return address will get you erratic behaviour at best, but more likely a
segfault (because the data+stack segment is much larger than the code
segment and stack addresses are at the top of said segment, so a stack
address as PC is probably invalid).

- multiple instances of the same program can share a code segment. This
saves memory, memory transfers and counters fragmentation issues possibly
caused by using large amounts of small segments.

On the other hand, what you said about the stack and data areas is true:
they share the same segment, and it is fixed. There is no way to prevent a
stack from growing into the heap (only a possibility of detecting it while
context switching) and there is no way to give an application more memory
than it was assigned at process creation time. This last thing especially
causes the common "Not enough core" error message when running programs
that (sometimes) require lots of memory.

Regards,

Jens

--
Jens de Smit
Student Computer Science | Vrije Universiteit Amsterdam
jfdsmit@xxxxxxxxx | http://www.few.vu.nl/~jfdsmit
"[In the end, people] get furious at IT that the goddamn magic isn't working"
-- Stewart Dean
.

Relevant Pages

  • Re: Questions about Minix
    ... Of course you still need to allocate chunks of contiguous memory, ... in user mode and at kernel level if you need dynamic ... I read "data segment". ... a stack from growing into the heap (only a possibility of detecting it ...
    (comp.os.minix)
  • Re: Questions about Minix
    ... I think I got to that conclusion that .text shared the same memory chunk ... segment to processes from the beginning, and a data segment that did not ... True, but this would limit your stack size to some predetermined value, ... you still have plenty of heap left. ...
    (comp.os.minix)
  • Re: execve() and heap memory
    ... bss, and stack of the calling process are overwritten by ... This is typically placed in memory above the 'text' (or at ... literals) in the text segment. ... Stack instructions in the 'text', ...
    (comp.unix.programmer)
  • Re: shell code on minix
    ... compilers may be different. ... The stack segment in a i386 processor are not executable and analyzing in details the assembler generated in the Minix and Linux you may see what trick are used and why it works on Linux. ... Reading any book on the i386 family of processors would be of help to understand how memory protection and allocation works. ...
    (comp.os.minix)
  • Re: How to develop a random number generation device
    ... but if you can manage to create a buffer overflow in a kernel process ... (the TCP/IP stack being a common target here, ... A messed up data segment is still the data segment. ...
    (sci.electronics.design)