keeping apps from seeing other memory by switching segments

[earlz]

Well I have a problem with my current concept on multitasking
I want to have like a data and code segment for apps(set to ring3) but if another app(also at ring3) changed their segments then they could do anything to other apps memory and code

is there any way to prevent this problem easily?

my only idea is to have copies of the gdt stuff but that just seems overly massive.. 48 bytes per entry(I think)*64k is quite a bit..

[Kevin McGuire]

You could use paging to accomplish that.
http://www.osdever.net/tutorials/paging.php?the_id=43

[Pype.Clicker]

indeed, the most common solution is to have each program in its own address space via paging.

In Single Address Space systems, you could still want to use segments to enforce protection. A first option would be to give each tasks its LDT with its own segments (e.g. cs=0x14, ds=0x1c, ss=0x24) and to switch to the new LDT on task switches. All the programs could then access is what's in their LDT and what's in the GDT (e.g. globally shared stuff, system descriptors, etc). Alternatively, you could simply rewrite the description of the few per-program descriptors on task switch (at least two of them, being 8 bytes each) into the GDT, but honnestly i don't see the advantage on an architecture that has LDTs

oh, and all that will miserably fail in 64-bit mode, of course (thanks AMD guys for that )

[Brendan]

Hi,

IMHO the concept of "single address space" systems fails due to technical reasons - physical memory management problems, swap space efficiency, fragmentation and portability. Some of these problems can be avoided by using paging and segmentation, but then you'd need to wonder if the benefits are worth the hassle (compared to "paging only" systems).

The only sane use of segmentation I've come across is "small address spaces" (or address space multiplexing), where a single address space may be split into several fixed size parts and each part holds an independant process (for e.g. up to three 1 GB "small address spaces" sharing the same page directory, where any of the processes may be migrated to it's own 3 GB address space if it ever grows too large). For a description of this technique and some discussion of the performance differences, see this white paper.

The only other thing I'd consider using segmentation for is reducing the CPL=3 code segment limit in systems that don't support the NX (No eXecute) paging flag. In this case you'd have a single CPL=3 code segment descriptor in the GDT and change the segment limit during task switches. This is fairly simple and works fairly well, as long as things like shared libraries aren't a problem.


Cheers,

Brendan

[Kevin McGuire]

Thanks, Brendan. The white paper gave me some insight into the comparison of context swiches for a microkernel and a monolithic kernel indirectly by discussing the moderate to low speed improvment of using a small space to help reduce the cache cooling, and invalidation which I find very interesting too.

I even did a google search of the paper, and found a repository of interesting white papers for the L4 Ka microkernel apparently. Very neat. Thanks.

http://i30www.ira.uka.de/research/documents/l4ka/