its entirely possible to implement segments on top of paging. what you need to do is add the kernel abstractions for implementing call gates that change segment visibility, and write some infrastructure to manage unions-of-a-bunch-of-little-regions. I haven't implemented this myself, but a friend did on a project we were working on together and as a mechanism it works perfectly well.

getting userspace to do the right thing without upending everything is what killed that project

▲

Joker_vD 3 days ago | parent | next [-]

There is also a problem of nested virtualization. If the VM has its own "imaginary" page tables on top of the hypervisor's page tables, then the number of actual physical memory reads goes from 4–6 to 16–36.

▲

aforwardslash 3 days ago | parent | prev | next [-]

If I understood correctly, you'te talking about using descriptors to map segments; the issue with this approach is two-fold: it is slow (as each descriptor needs to be created for each segment - and sometimes more than one, if you need write-execute permissions), and there is a practical limit on the number of descriptors you can have - 8192 total, including call gates and whatnot. To extend this, you need to use LDTs, that - again - also require a descriptor in the GDT and are limited to 8192 entries. In a modern desktop system, 67 million segments would be both quite slow and at the same time quite limited.

▲

convolvatron 2 days ago | parent [-]

no, not at all. we weren't using the underlying segmentation support. we just added kernel facilities to support segment ids and ranges and augment the kernel region structure appropriately. A call gate is just a syscall that changes the processes VM tables to include or drop regions (segments) based on the policy of the call.

	▲	aforwardslash 7 hours ago \| parent [-]
		Humm very interesting approach, are there any publicly available documentation links?

▲

tliltocatl 3 days ago | parent | prev | next [-]

But that wouldn't protect against out-of boundary access (which is the whole point of segments), would it?

▲

convolvatron 2 days ago | parent [-]

thats enforced by the VM hardware - we just shuffle the PTEs around to match the appropriate segment view

▲

rep_lodsb 2 days ago | parent [-]

As long as it's a linear address space, adding/subtracting a large enough value to a pointer (array, stack) could still cross into another "segment".

	▲	convolvatron a day ago \| parent [-]
		but those wouldn't be mapped unless you have crossed a call gate that enabled them. the kernel call gate implementation changes the VM map (region visibility) accordingly

▲

nine_k 3 days ago | parent | prev | next [-]

Indeed. Also, TLB as it exists on x64 is not free, nor is very large. A multi-level "TLB", such that a process might pick an upper level of a large stretch of lower-level pages and e.g. allocate a disjoint micro-page for each stack frame, would be cool. But it takes a rather different CPU design.

▲

formerly_proven 3 days ago | parent | prev [-]

"Please give me a segmented memory model on top of paged memory" - words which have never been uttered

▲

nine_k 3 days ago | parent [-]

There is a subtle difference between "give me an option" and "thrust on me a requirement".

	▲	bschmidt25014 3 days ago \| parent [-]
		[dead]