Re: Memory protection between compilation units?

Mateusz Viste <mateusz@not.gonna.tell> wrote:

 
That said, detecting out-of-bounds array access is no panacea. Memory
corruption can arise from various sources, such as dangling pointers or
poorly managed pointer arithmetic.

AFAICS there is no reason for explicit pointer arithmetic in well
written C programs.  Implicit pointer arithmetic (coming from array
indexing) is done by compiler so should be no problem.  Like in
case of bounds checking using other languages can help in avoiding
dangling pointers.

Hence why I was looking in the direction
of the MMU. All compilation units of a program share the same set of TLBs.
I figured there might perhaps be a way to isolate a given compilation unit
in different TLBs, effectively sandboxing its memory, then make this unit
communicate with the rest of the program via shm when shared memory
accesses are needed.

Changing TLB-s content is rather expensive.  Also what "its memory"
is supposed to mean?  Normaly functions in a C program pass pointers
to other functions, so several functions can legaly access rather
large and varying in time parts of memory.  Best approximation to
your idea available in PC hardware is 286/386 segmentation.  But
it proved to be quite inconvenient, so "everybody" is now using flat
mode.  One could try to emulate segmentation using paging hardware,
and your idea clearly goes in such direction, but it is unlikely
to work well.

--
                              Waldek Hebisch