Using segmentation without paging is a bad design-choice. The only really useful approach for a segmented design is to use segmentation on top of paging.

Using segmentation without paging is a bad design-choice. The only really useful approach for a segmented design is to use segmentation on top of paging.

Having gotten a long way with my 64-bit environment now (which uses only paging), and comparing it to my usual (segmented-paged) environment, I think I can conclude the pros and cons:

1. Syscalls in a segment-paged environment can be run without validation (the validation can be built-into the API by defining the appropriate selectors for user-mode). This is true even if applications are flat.

2. Syscalls in a paged-only environment needs extensive parameter evaluation in kernel before being passed to server.

3. Separation with segmentation in kernel is an adequate method of providing protection between modules in a kernel.

4. Separation with paging only in kernel is typically not an adequate method, instead many designs use a microkernel and let driver modules run in isolated user-address spaces. At least similar protection as with segmentation cannot be achieved without a microkernel design.

5. Long mode addresses can be used in a pseudo-segment related manner by treating the upper 32-bits as a segment, and keeping various pieces at "random" locations. However, typical uses of 64-bit mode use the 2G lower addresses or 2G higher addresses, which provide no protection at all in addition to a 32-bit flat memory model.

Since there are pros and cons of each of these designs, it is not possible to tell which is best and which is most effective. It also depends on the speed of segmentation and paging on the particular processor, and how syscalls are constructed by the OS.

This depends on what you're protecting.

If you're only protecting processes from other processes then:

• for "flat paged" processes you only need a "top of memory" variable (e.g. set by something like a "sbrk()" function) and you'd do something like "if( address + size > processData->memoryTop ) return ERR_DENIED;"
• for segmentation you'd have a small number of large segments and it's almost identical (e.g. "if( offset + size > segment->limit ) return ERR_DENIED;") unless you want a crappy kernel that crashes (general protection fault) because you failed to do validation

If you're protecting a process from itself (e.g. trying to detect things like "array index out of bounds" and accessing freed memory) then paging doesn't help at all. Segmentation could be used for this (e.g. new segment created by "malloc()" and segment destroyed by free()"), but it's likely to be a lot slower than using a managed language because of the frequent segment register loads and syscalls for creating and destroying segments, it won't detect lots of problems (e.g. a process trashing its own data) anyway and you end up running out of GDT/LDT entries. Basically, protecting a process from itself only matters for debugging (and the overhead of segmentation or managed languages isn't justified when you're not debugging) and using segmentation for this is a bad idea.

For monolithic kernels the basic idea is that kernel modules can be trusted and therefore "adequate" means no protection between modules is needed at all (and no overhead). For micro-kernels the basic idea is that these modules can't be trusted and therefore it's necessary to (for e.g.) prevent one module from accessing another module's data and also prevent a module from accessing a normal process' data.

Separating modules with segmentation can work, but if you trust the module then the overhead isn't necessary and if you don't trust the module then you have to make sure one module can't load another module's segments or load a normal process' segments (which means having an LDT for each module and each process, and doing "LLDT" every time control is passed). I actually used this for one of my earliest protected mode kernels and abandoned the idea because half the kernel's code ended up duplicated (different virtual memory management for normal processes and modules, different IPC for normal processes and modules, different executable file formats for normal processes and modules, different kernel APIs for normal processes and modules, etc). The other problem was space - the 4 GiB virtual address spaces were split into 2 GiB for the process, 1 GiB for the kernel, and 1 GiB shared by all of the "system modules"; which meant that you run out of space for modules very quickly (e.g. two video card drivers with 512 MiB of memory mapped IO each and 2 GiB of "VFS disk caches" and you're screwed). Of course I shifted to a micro-kernel, so a lot of code duplication disappeared and now each "system module" gets 3 GiB of space to use.

Typical use of paging in long mode is "several TiB" for each 64-bit process, a full 4 GiB for each 32-bit process and about 512 GiB for kernel. Note: I don't know why people seem to limit the kernel to 512 GiB (especially for monolithic kernels), but I assume it's so that the kernel is contained in one page directory pointer table.

For monolithic kernels the basic idea is that kernel modules can be trusted and therefore "adequate" means no protection between modules is needed at all (and no overhead). For micro-kernels the basic idea is that these modules can't be trusted and therefore it's necessary to (for e.g.) prevent one module from accessing another module's data and also prevent a module from accessing a normal process' data.

Separating modules with segmentation can work, but if you trust the module then the overhead isn't necessary and if you don't trust the module then you have to make sure one module can't load another module's segments or load a normal process' segments (which means having an LDT for each module and each process, and doing "LLDT" every time control is passed).

I actually used this for one of my earliest protected mode kernels and abandoned the idea because half the kernel's code ended up duplicated (different virtual memory management for normal processes and modules, different IPC for normal processes and modules, different executable file formats for normal processes and modules, different kernel APIs for normal processes and modules, etc). The other problem was space - the 4 GiB virtual address spaces were split into 2 GiB for the process, 1 GiB for the kernel, and 1 GiB shared by all of the "system modules"; which meant that you run out of space for modules very quickly (e.g. two video card drivers with 512 MiB of memory mapped IO each and 2 GiB of "VFS disk caches" and you're screwed). Of course I shifted to a micro-kernel, so a lot of code duplication disappeared and now each "system module" gets 3 GiB of space to use.

Typical use of paging in long mode is "several TiB" for each 64-bit process, a full 4 GiB for each 32-bit process and about 512 GiB for kernel. Note: I don't know why people seem to limit the kernel to 512 GiB (especially for monolithic kernels), but I assume it's so that the kernel is contained in one page directory pointer table.

In practice I don't think there are many ways to use segmentation where the advantages outweigh the disadvantages.

Thanks rdos for the answer, it was really helpful. By the way, you mean something like L4 microkernels? It uses the same page table for multiple processes I guess, but separates the address spaces using Segmentation, right?

Are there any other approaches for implementing Segmentation on top of Paging? Thanks.

Yeah, this is one of my big frustrations with 386 segmentation. If I were designing a segmented paged architecture, I'd have things structured something like this:

Instead of dividing things up into a local and a global descriptor table, I'd put all segment descriptors into the GDT (though I might break it up into several tables so that a contiguous block of memory didn't have to be reserved for it). Then, instead of a local *descriptor* table, I'd have each code segment (and possibly each stack segment) have a pointer to a local *selector* table (LST). There would be two kinds of selectors, global selectors, which would be valid for direct use as indexes into the GDT (though loading a segment register this way would only be permitted in kernel mode), and local selectors, which would be per-process (or rather per-code/stack segment) and would index into the LST. Each entry in the LST would then contain a global selector value and various permission bits (so that a globally read/write segment could be restricted to read-only access for a particular program, for instance).

When a local selector was used in a segment register load (this would be required in user-mode), the hardware would do the following:

1)Use the local selector as an index into the LST to select an LST entry.
2)Use the global selector found in the selected LST entry as an index into the GDT.
3)Load the segment register in question from the selected GDT entry. If any permissions in the LST entry are more restrictive that those in the GDT entry, load those fields of the segment register with the corresponding fields of the LST entry instead.

This would allow a user-mode program to call a user-mode driver directly without message-passing through the kernel or a full context switch, while still preventing the program in question from calling just any code on the system it wanted to, and while preventing the driver from accessing private program data.

I don't understand what this would improve. It is assumed that LDT is per process or even per application (it's up to the OS to decide and implement). The OS only use lldt to load a new local table.

That's already possible. The mechanism is called "call-gate", and provide exactly this functionality.

Segmentation is a waste of time in the 21st Century.

I am fairly certain the ARM architecture doesn't have segmentation.

AMD64 has virtually no segmentation.

The Motorla 68000 never had segmentation and it could be connected to the M68451 MMU to implement paging.

The Intel 286 Processor was a disaster, it was badly designed. Paging had existing on mainframes since the 1960s and Motorola had the M68451 MMU.

Intel should have had enough foresight to build a CPU with paging as the ONLY protection mechanism. Segment registers only maintain 8086 compatibility (simple << 4 and add). The GDT was an extremely bad design decision. As we know Intel realised their mistake and released the 386.

Why do you think we still have a very popular x86 architecture while basically all the architectures of similar age has disappeared? Simple answer: x86 is a recipe for success. Hardware compability is much more successful than software compability.

Paging is not an effective protection mechanism. It is a complete disaster for protection unless multiple address spaces are also used. Basically, paging only has no better protection than real mode where anything can be overwritten by anybody.

What's more, the way most OSes uses long mode is no better as typical OSes typically doesn't use the additional address space in a smart way to increase protection.

The culpit rather is the lousy C language which cannot handle neither segmentation nor page level data protection in an effective way. For instance, the typical heap manager for C will generate localized storage sections where both other's data and control-blocks can be overwritten when pointers fail in C.

There are no smart ways to use the additional address space to increase protection. Crossing your fingers and hoping that malicious code won't try to access something in a different part of the virtual address space is purely idiotic.

This is not because C (the language) is lousy - it's perfectly capable of using segmentation and page level data protection (whatever that is). The problem is that compilers don't support this because nobody cares, and nobody cares because segmentation is a waste of time in the 21st Century.

Of course there is. It is all about statistics. If all your kernel is within -2 to 2GB, and the datastructures are packed close together, the probability that randoms integers could be valid addresses is quite large (and increases with size of kernel). The probability that pointers accessed out of limits will create "silent overwrites" is also large. The way to deal with these problems is to use random addresses in the middle of the address-space, not the top -2GB or bottom 2GB.

We have managed (interpreted languages) because C sucks at fundamental data protection issues. Issues that could be solved with hardware, but cannot because no matter how smart hardware we develop, C cannot use it intelligently.

Do you think that paragraph makes sense? Try this one: "Segmentation is not an effective protection mechanism. It is a complete disaster for protection unless multiple segments are used. Basically, segmentation has no better protection than real mode where anything can be overwritten by anybody."

Of course with paging and only one virtual address space you can protect supervisor pages from CPL=3 code, and with segmentation and only one segment you can't even do that. Therefore a system that uses paging but fails to use it properly and only uses one virtual address space is still better than a system that uses segmentation but fails to use it properly and only uses one segment.