Intel is continually adding new processor features. Some require virtually no additional system software support or are entirely transparent to software; others have touch points across the software stack. FSGSBASE is one feature that falls into the latter category.
FSGSBASE is an Intel® architecture extension that allows applications to directly write to the FS and GS segment registers. This allows fast switching to different threads in user applications, as well as providing an additional address register for application use. In addition it allows the kernel to do more efficient context switching.
This article gives an overview of FSGSBASE, including specific software touch points using Linux* as an example (although the guidance is applicable to other operating systems). It concludes with some consideration if these touch points are not addressed.
Overview and Hardware Background
The FS and GS base registers have existed on x86 for decades and were originally used as part of the segmentation mechanism. Even though software has moved away from using the segmentation feature, these registers are still used for other purposes.
FSGSBASE is a processor feature, introduced in 3rd Generation Intel® Core™ processors based on the Ivy Bridge microarchitecture, which allows expanded direct access from user level software to the FS and GS base registers. Previously, applications had to access these registers via system calls, which can be much slower than direct access. Enabling direct access also effectively grows the set of registers available to applications, improving performance.
Enabling and Potential Impact
Historically, Linux used bit 63 of the GS base register to determine if the value was written by the kernel. This has been a safe assumption because the only way for an application to write to the GS base register was with the ARCH_SET_GS arch_prctl() system call. The kernel would return an error if an application attempted to set bit 63 of the GS base register.
If the kernel failed to differentiate between its own GS base value and an application’s value, an application could trick the kernel into using the wrong data for its per-CPU data structures. These structures contain data, like stack pointers, which affect control flow and might be leveraged by an exploit for malicious purposes.
The FSGSBASE architects anticipated these kinds of issues and included an opt-in as part of the architecture. System software, such as Linux, must first set a bit in a privileged control register (CR4.FSGSBASE) before the FSGSBASE feature will function. The inclusion of this bit allows each operating system to opt in to FSGSBASE only after it has removed any potentially unsafe assumptions, such as the value of GS base bit 63.
However, some software projects that desire the functionality of FSGSBASE might manipulate CR4.FSGSBASE without also removing assumptions about the value of GS base bit 63. This could potentially allow malicious software to manipulate the GS base.
Intel recommends that software projects that enable the FSGSBASE capability keep or add assumptions about the value of the GS base bit 63.
Implementation
The legacy Linux kernel has assumptions for the FS/GS base register. The base address corresponds to the selector, and the range of the GS base address is different between privilege modes. To enable FSGSBASE, the Linux kernel has to deprecate FS/GS base across the board. Context switching, ring transition, and process trace system calls are the affected elements. In context switching and process trace system calls, the kernel needs to manage the FS/GS base entirely separate from its selector. The ring transition code has to be insensitive to the GS base address. Linux kernel 5.9 and later versions contain these changes and support FSGSBASE.
Alternatively, experimental projects such as those described above should consider providing backport versions for the 5.4 Long-Term Support (LTS) kernel1.
Guidance for Experimental Projects
Several experimental Library OS (LibOS) implementation projects aim to run unmodified Linux applications on Intel® Software Guard Extensions (Intel® SGX) by providing a POSIX runtime environment for applications. All such LibOSes run modified libraries inside the enclave along with the LibOS. GNU Library C relies on thread-local storage (TLS) to keep all thread-private variables. Thread-local storage on x86-64 architectures are maintained by FS/GS base registers. Because Intel SGX enclaves do not allow making system calls from an enclave, however, these systems can’t use the system calls provided by Linux.
The FSGSBASE hardware feature provides an alternative to making these system calls, making it attractive to Library OSes. Several implementations have manipulated CR4.FSGSBASE without removing all OS assumptions about the values of the base registers:
Given the purpose of this bit, Intel recommends that it be used with caution and never in production environments unless accompanied by a complete OS implementation. Incomplete implementations, such as those listed above, can be exploited to gain privilege escalation.
Conclusion
FSGSBASE is a hardware feature that brings new capabilities to software running on Intel® processors, including making it easier to run unmodified software with the protections of Intel SGX. However, users should enable this feature according to the guidance in this document to reduce of the risk that systems are exposed to malicious software.
Footnotes
- For Graphene, see: https://github.com/oscarlab/graphene/blob/91f8a605e119814c53fada36b22f9…
Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources