Is some connection between using x86 segmentation and a possible implementation a thread package? I've been told that usually x86 segmentation is implemented in operating systems these days with an identity function (0 offset, unlimited limit), but can segmentation somehow be useful when dealing with multithreading?
4
-
How would segmentation ever be useful on x86?– DeadMGMar 20, 2012 at 4:36
-
@DeadMG 32-bit VMWare uses segmentation extensively to protect the hypervisor from the guest kernel(s).– zvrbaMar 20, 2012 at 12:20
-
@DeadMG: Google's NaCl (Native Client) on x86 uses it to sandbox untrusted code.– MSaltersMar 20, 2012 at 13:14
-
For compatibility between x86-32 and x86-64, you certainly want to use an identity function for CS/DS/SS since x86-64 supports nothing else.– MSaltersMar 20, 2012 at 13:22
Add a comment
|
2 Answers
AFAIK, Windows is using one segment register to point to the thread specific variable area for the thread.
Note that what is useful here isn't the segmentation -- I think limit and protection are not really used, and IIRC that's the only thing which is now supported in 64 bits mode --, but the fact that segment registers had fell into disuse and so were available to be used simply as base register without impacting existing code.
answered Mar 20, 2012 at 7:46
So I found out that one interesting use of segmentation in thread packages (not saying this is actually done anywhere, but it's at least a potential use) is to manipulate the stack segment so that threads within a single process can share an address space, but not collide on the same stack. Each thread has its own stack, but the code running in the thread doesn't have to know where its stack is--if it doesn't try to manipulate its own stack segment register, the register will be set when it starts to point to an entry in the LDT, which leads it to some stack designated specifically for it in the process's address space.
This is similar to how I imagine kernels work when they run on a system with multiple cores. When an interrupt or exception occurs on one core, stuff gets pushed the kernel stack by the hardware--but this could mess up the stack if the kernel is also running on other cores at the moment that the exception/interrupt occurs. Instead, each core's kernel could have a separate stack, designated by entries in the IDT and GDT.