x86x86-16memory-segmentation

8086 segment selector


Is there some "supervisor" bit to not let the "user space" do something like

mov CS, 200h

What kind of protection is there?


Solution

  • On the actual 8086 CPU? No. The advanced protection features only really started appearing with the 80286. There were no restrictions on what programs could set the code segment to on the 8086.

    With segment registers (in real mode), there were no protections or virtual memory, and the physical address was calculated by a simple shift and add. For example, 1234:5678 referred to physical address 179B8 as per:

    12340
     5678 +
    -----
    179B8
    

    In protected mode, the values in CS (and DS, ES, and so on) changed from segment registers to selectors and they had to have entries in a descriptor table (eg, the global GDT or local LDT).

    The selector was used to look up an entry in the relevant table and retrieve things like base address, size, protections, and so on.

    I don't think it was the loading into a selector register that caused the violations. Rather it was the use of a selector above your privilege level (or other things, like trying to access memory beyond the end of the block).

    For CS, that would happen pretty quickly after you changed it (as you tried to execute the next instruction). Other registers may take longer to fault because you may not use them straight away.


    Just keep in mind that an instruction like mov cs, 200h, even if it existed, would be a rather strange way to effect a jmp (as would any instruction that changed cs independently of ip).

    It would require you to ensure the code you wanted to transfer control to had a very specific offset in the memory referenced by the target selector since ip would not be changed by that instruction (beyond the normal small increment that normally happens with sequential execution, of course).