Is segmentation completely not used in x64?

Question

In x86, when you want to access a memory address, you would specify an address that would be translated into a memory address through two stages: segmentation, and paging:

But is segmentation also used in x64? (I think it is not used, but I am not sure if it is not used in all cases, or are there some cases where it is used).

Spiny

It is my understanding that segmentation is an artifact of the fact that pre-x64 Intel chips do not have a 64 bit address bus. In x64, in contrast, the address registers are 64 bits and so is the address bus, so everything uses native 64 bit addressing. However, I haven't done much Intel assembler since the 8086, and things have changed just a bit since those days. :) – Arnelle

Segmentation is not used, en.wikipedia.org/wiki/… – Foremost

In 64-bit long mode segmentation is used in a limited way. FS and GS segment registers can have a non zero base. The other segments are always assumed to be a 0 base with no limit (a flat memory model spanning the entire 64 bit virtual memory space). With GS and FS the base comes from values set in model specific registers. – Stator

Long mode includes 32-bit and 16-bit compatibility submode that can run protected mode code that use segmentation (not to be confused with legacy mode that can do that, and do real mode and v8086 mode). 64-bit long mode is where the segmentation doesn't really apply (except for GS.base and FS.base) – Stator

related: Linux memory segmentation asked how Linux uses segmentation to organize memory. Answer: it doesn't, not even in 32-bit mode. As Margaret says, segment registers are just used to keep the CPU happy and tell it what mode to run in. (Except for fs or gs for thread-local storage.) – Infinitive

@PeterCordes I think this is a duplicate of Why segmentation cannot be completely disable?. – Guess

Answer 1

For the purpose of the picture you posted, segmentation is only used when the addressing mode uses the registers fs or gs (because these were being actively configured with a non zero base by Linux and Windows).

Segmentation works remarkably different in protected (32-bit) and long (64-bit) mode with respect to real mode (16-bit).
Particularly, a segment is not just a base and a limit but a set of attributes loaded from two tables (GDT or LDT) filled with segment descriptors.

For all segment registers but fs and gs the CPU ignores the base when computing the effective address (a.k.a. offset), an action that has the same effect as using 0 for the base.
Furthermore, for all the segment registers, it performs no limit check (however the linear address must be canonical).

It's worth saying that when loading a segment register the CPU still loads all the information from the segment descriptor in the GDT/LDT (including the base and the limit).
This is necessary to support compatibility mode (32-bit semantic), in fact the segment descriptors for code and data have not been expanded to have a 64-bit base and limit (after the effect of the granularity bit).
That's why the bases for fs and gs are specified separately in two 64-bit MSR registers.
The Intel SDM claims that the fs and gs bases are physically mapped to these 64-bit MSRs, it's not clear to me then if loading fs and gs from a segment descriptor will also set the MSRs. That should be the case but I haven't investigated (EDIT prl did and confirmed this is the case).

While bases and limits are gone but for a pair of registers, all other checks remains.
Particularly the DPL (the privilege specified in a descriptor) of the code segment sets the CPL (the privilege of the executing code).
The stack segment must have a DPL equals to the CPL (and so also is for another privilege called RPL).
cs must still be loaded with a code segment, readable and writable attributes are still enforced (possibly but for fs and gs).
All the system descriptors remains (call gates, TSS selectors and so on).

So all the protection mechanisms (but for the limit) of the segmentation remains, so I won't say it is not used.
Actually, the segmentation machinery is deeply integrated in the way the CPU enter a new mode of execution (with protection), it's impossible not to use it.
Of course, the linear address translation is not using it anymore (but for the usual two fs and gs), and exactly due to these registers I think it's better to still keep your picture in mind.

There are a few exceptions to the protections listed above:

• fs and gs have no attribute check (as per Intel SDM), this could mean that it would be possible to load a non-readable code segment and read from it or a non writable data segment and write to it. This would contradict the SDM which also states that "Segment selectors for code segments that are not readable or for system segments cannot be loaded into data-segment registers (DS, ES, FS, and GS)" or more generally "No instruction may write into a data segment if it is not writable. No instruction may read an executable segment unless the readable flag is set.".

• The readable bit of code segment is not functioning normally. Literally from the SDM: "the remaining fields function normally (except for the readable bit in the type field)" but then it doesn't go into telling what it exactly does instead (presumably nothing, it is ignored).

• Null selectors are always valid. This is exploited during a privilege changing control transfer (which changed with the new 64-bit mode).

Nubble

Since it's Friday afternoon, I went ahead and wrote code to check that when FS and GS are loaded from a descriptor, it does change the value of the corresponding MSR. (I tested it on a Kaby Lake, but it would be very surprising if it varies between implementations.) – Retrorocket

One other way in which segmentation system makes a different in 64-bit mode is that a non-canonical address generates a Stack Fault Exception if the base register is RBP or RSP and a General Protection Exception otherwise. – Retrorocket

@Retrorocket Great job! Thank you for the time you spent testing it! – Nubble