Instruction/Data split implementation

Limit damage from buffer overruns
MINIX 3 uses fixed-length messages for internal communication, which
eliminates certain buffer overruns and buffer management problems.
Also, many exploits work by overrunning a buffer to trick the program
into returning from a function call using an overwritten stacked
return address pointing into the overrun buffer. In MINIX 3, this
attack does not work because instruction and data space are split and
only code in (read-only) instruction space can be executed.

-- [url]http://www.minix3.org/reliability.html[/url]

Concerning the above, how does Minix implement this on x86? Failing a
native NX bit, does it use Supervisor Bit Overloading as originally
used by PaX; or does it use segmentation as used by PaX SEGMEXEC
implementation; inaccurate code segment limit tracking as done with
Exec Shield and OpenBSD; or another method?

> Concerning the above, how does Minix implement this on x86? Failing a[color=blue]
> native NX bit, does it use Supervisor Bit Overloading as originally
> used by PaX; or does it use segmentation as used by PaX SEGMEXEC
> implementation; inaccurate code segment limit tracking as done with
> Exec Shield and OpenBSD; or another method?[/color]

For binaries with instructions and data split, Minix does not use a
linear memory model in which each segment points to the same memory.
Rather it uses a truly segmented approach in which CS and DS point to
different non-overlapping memory and CS is non-writable (note: ES and
SS equal DS).

Since CS is not writable and memory addresses in CS are not available
through DS, ES and SS, self-modifying code is impossible and hence it
cannot be used by exploits.

--
With kind regards,
Erik van der Kouwe

Den Tue, 10 Jun 2008 06:22:36 +0000 skrev "Erik van der Kouwe" <vdkouwe:
[color=blue]
> For binaries with instructions and data split, Minix does not use a
> linear memory model in which each segment points to the same memory.
> Rather it uses a truly segmented approach in which CS and DS point to
> different non-overlapping memory and CS is non-writable (note: ES and SS
> equal DS).
>
> Since CS is not writable and memory addresses in CS are not available
> through DS, ES and SS, self-modifying code is impossible and hence it
> cannot be used by exploits.[/color]

What about code that has a legitimate need to be self-modifying? In
particular I mean VMs with JIT compilers, which are the cornerstone of
most interesting languages. Inability to have safe and performant
languages would be really a huge blow to the usability, and ultimately
reliability of Minix, as it'd force the use of C in many more places than
otherwise necessary.

Cheers,
Maciej

> > For binaries with instructions and data split, Minix does not use a[color=blue][color=green]
> > linear memory model in which each segment points to the same memory.
> > Rather it uses a truly segmented approach in which CS and DS point
> > to different non-overlapping memory and CS is non-writable (note:
> > ES and SS equal DS).
> >
> > Since CS is not writable and memory addresses in CS are not
> > available through DS, ES and SS, self-modifying code is impossible
> > and hence it cannot be used by exploits.[/color]
>
> What about code that has a legitimate need to be self-modifying? In
> particular I mean VMs with JIT compilers, which are the cornerstone
> of most interesting languages. Inability to have safe and performant
> languages would be really a huge blow to the usability, and
> ultimately reliability of Minix, as it'd force the use of C in many
> more places than otherwise necessary.[/color]

In this case you use the -com switch for ACK or you use GCC. In both
cases code is put in the data segment, causing it to be writable. In
this case the protection against self-modifying code is obviously lost,
and it is no longer possible to share the code segment between multiple
instances of this program, so as to maintain the seperation between
processes.

--
With kind regards,
Erik van der Kouwe