Which OS rely heavily on segmentation?

[sturmstiger]

Both linux and windows use very few segments and rely on different page directories to separate processes, even though segmentation rather than paging seem to be IA32's "intended" mechanism for separation and protection. Can anyone list a few OS that really rely on multiple LDTs on IA-32? And what are their reasons for using or not using segmentation?

A another question: why linux use interrupts instead of call gates for system calls? Can anyone compare their advantages and disavantages (suppose portability is not a concern)?

Thanks a lot.

[AR]

Segmentation was inherited from the early 8086 and its successors which couldn't handle more than 64KB of memory so the concept of segments was added to allow more memory to be used. I don't know any commerical OSes that use it extensively, or at all (realmode OSes like DOS do but I doubt that's what you want). When 32bit mode was added, so was paging and most people have used that since.

Call Gates are faster but are not be portable across platforms, the x86 also features "fast system call" instructions, SYSENTER and SYSCALL, which provide fast context switches to the Kernel but require a flat memory model without segmentation.

[Candy]

I heard OS/2 did a lot with them, and I believe it to be commercial too. Up to a certain level, that is.

[Pype.Clicker]

afaik, MULTICS was heavily relying on everything the IA-32 offers: multiple rings, multiple segments and things alike.

I also have several segments in Clicker (among other things, one for each kernel and user stack), but i suppose that's not what interrest you most.

[mystran]

Hmm... IIRC MULTICS had 7 rings... so IA-32 doesn't offer enough for that beast.

[Colonel Kernel]

I thought MULTICS predated IA-32 by many years...

[mystran]

I thought MULTICS predated IA-32 by many years...

It did.

[Candy]

Am also using a small bit of segmentation in my own OS, but it's mainly as a fixed offset in a location user programs can't change. The GDT for each processor loads a certain value in the 0x38 selector location, then switches GS to it and uses that to store the thread data. Then it can switch safely etc. For real segmentation, don't look at me. I really like the idea, but since there's no compiler supporting it and since all 64-bit arches don't support it I stopped using it nonetheless.

[pini]

I was using segmentation and a per process LDT. It was first designed to unable process to access certain memory location where I was storing information about the process (process struct) and also to provide a strong protection against side effects like buffer overflow exploits (executable stacks, and so on).

I wrote 'was' because I don't rely on segmentation anymore since Intel announced that they won't support segmentation in their future architectures.
I thought it would be better not to rely on a feature that seems to be doomed to disappear.

PS: I found segmentation very attractive, from a secure point of view, but as most kernel developpers don't use it, architecture builders don't see any reason to continue using it. And if they suppress segmentation, no kernel developper will ever use it again, and so on...

[sturmstiger]

I found segmentation very attractive, from a secure point of view, but as most kernel developpers don't use it, architecture builders don't see any reason to continue using it. And if they suppress segmentation, no kernel developper will ever use it again, and so on...

That's also my major concern on whether relying on segmentation or not. I am focusing on security in the OS I am trying to build , and IA-32 segmentation seems to be exactly the thing I want. But nobody (especially architecture builders) seems to like it...

[Colonel Kernel]

I think the kinds of security issues that segmentation addresses are being handled increasingly at a higher level of abstraction -- at the language and run-time environment level. The JVM and the CLI are two examples that spring to mind. VMs are an example of the proverbial "extra level of indirection" that solves all software engineering problems.

I expect that as time goes on, the idea of letting any machine code just run willy-nilly, even in user space, will seem increasingly ludicrous from a security standpoint, especially when safer alternatives are available. Of course, even software that runs in a VM is only as secure as the VM itself, but it certainly reduces the exposure.

[AR]

I personally don't like the abstraction layers imposed by virtual machines, it makes it difficult to operate the computer in a "natural" way.

As far as I can see, any security problem that is not directly caused by the hardware, like a flaw in the CPU design, can be easily regulated. Why do we need VMs to control a program's access to files? Why can't they just code that same logic directly into fopen()? Affect is the same and you can still write machine code without the performance hit of interpreted code. This is one of the things I want to experiment with, strict security policies built into core APIs that are as effective as VMs without VMs. From my perspective, locking a program in a cage (VM) just because you can't be bothered to build a fence is pure laziness.

[pini]

I personally don't like the abstraction layers imposed by virtual machines, it makes it difficult to operate the computer in a "natural" way.

I agree with you on this point. As we are building our own kernels, there's no good reason to use a VM to ensure security.
In the end, security level is this of the operating system and more specifically the kernel. If a kernel is unsecure, who can predict that a supposed "secured-in-a-VM" program would not treat the system ?.

Of course, using a VM prevents exploiting kernel bugs, but who can say the VM is not using (either voluntary or unvoluntary) a kernel security hole ?
I found it would be better idea to build a kernel that is designed for security, and segmentation helped this way.

Some architecture buildes say that segmentation is not useful anymore, as paging is a sufficient protecting mechanism, and that the processors needs more time to compute the linear address from the logical one.
This is true (even if paging is not as protecting as segmenation was), but with the current processor's speed they can reach nowadays, who cares if an instruction takes a few ns more for a addition ?
IMHO, even the security checks (segment limit, access rights...) are not justifying that the processor speed loss is significiant.

Stay safe.

[Colonel Kernel]

I personally don't like the abstraction layers imposed by virtual machines, it makes it difficult to operate the computer in a "natural" way.

What does "natural" mean in this context?

As far as I can see, any security problem that is not directly caused by the hardware, like a flaw in the CPU design, can be easily regulated.

If that were true, we would have a lot fewer worms and viruses running rampant, and apps would never crash because of a buggy shared library they've loaded. So... it can't be that easy to regulate.

Why do we need VMs to control a program's access to files? Why can't they just code that same logic directly into fopen()?

I can give you a powerful example of where a VM can enforce security restrictions that the OS (even with segmentation IMO) cannot. Example: Joe User has somehow been fooled into running some malicious code he downloaded (it happens... call Joe stupid, call him irresponsible, whatever -- you can't deny the power of social engineering and human stupidity). If this code is allowed to run as a plain old "unmanaged" app, then the only thing preventing it from accessing the file system is the identity of the user that it runs under. In this case, it was run (unwittingly) by Joe, so it's free to delete all Joe's files, much to Joe's chagrin.

Now, if all code run by the OS has to be verified and run by the VM, then this problem won't happen. Here's why -- in this case, the malicious app is trying to access the file system in a naughty way. Unfortunately, it is impossible to determine by static inspection of the app's bytecode whether it is doing anything "bad" or not in this case (normally, static verification can only uncover unsafe type-casts and things that could result in memory corruption... it isn't smart enough to determine intent from system calls being made). However, because the app (and everything else that runs in the VM) includes rich metadata that completely describes all the types and libraries being used, it is possible for the VM to inspect the call stack when system calls are being made, and figure out what code is doing the calling, where that code came from (in this case, hax0res-r-us.com), and whether it has permission to do what it's trying to do (in this case, no way). This is independent of the ID and privileges of the user running the code, and can't be implemented in hardware with tools like segmentation.

I know stack walking sounds slow, and it is, but the point is that it will only be used when running code that could have come from somewhere nasty.

Affect is the same and you can still write machine code without the performance hit of interpreted code.

VM does not imply interpreted. Most JVMs use JIT compilation, and both Mono and .NET always do. This itself gives rise to some interesting optimization policies, as the VM can profile running apps and feed that info back to the JIT so it can make better optimization decisions.

This is one of the things I want to experiment with, strict security policies built into core APIs that are as effective as VMs without VMs. From my perspective, locking a program in a cage (VM) just because you can't be bothered to build a fence is pure laziness.

A lot of arguments have been made on the basis of "laziness is bad". Unfortunately, a system is only as secure as its weakest point, and in my example above, that's Joe. And Joe is lazy, and stupid, and there's nothing we can do about it.

<Apologies to anyone on the forum whose name might actually be Joe>

[Pype.Clicker]

His true name is Joe Average (http://clicker.sourceforge.net/wiclicke ... Archetypes, from ProPOS project)

There are solutions to prevent Joe Average's documents to be deleted by a malicious program he downloaded: provide finer grained access control to resources. E.g. when installing a program, the program will have to present a "resources request list" to the system, like
- being able to contact web servers at smartupdate.application.org
- being able to read your "audio" documents

That would be fair for a FutureAmp player. Clearly, if your FutureAmp requests the ability to write/modify/remove your "spreadsheets" or "text" documents, something is wrong. Same if it tries to act like a mail server. The system can easily ensure that the operation the application performs as it said it should.