With the first release candidate of Linux 5. Linus Torvalds announced a historical change at the end of October: The one who has been working since 1991 The existing set_fs () mechanism should be phased out with the upcoming kernel version, if not on all, then at least on some CPU architectures.

Calling set_fs () typically enables subsequent userspace access functions to access the protected memory area of ​​the kernel – or removes this option again. However, the legacy of the old 386 days also caused serious security problems in the past. In this article, we’ll take a closer look at how set_fs () works, the dangers inherent in the function, and the consequences of its omission.

30 years set_fs () The kernel function set_fs () has been since Release 0. 10, i.e. since the end 1991, an integral part of the Linux kernel. At that time Linux was still tailored to the 80386 processor and inevitably used what this CPU offered.

The operating system used the FS- Register of the 386 ers to make the kernel or user space available for the functions to be called. Logical memory addresses are made up of a segment selector and an offset. Under normal circumstances, the segment selector in the FS register points to the user space. By setting the FS register to the kernel space with set_fs (), userspace access functions such as get_user_byte () can access the kernel space. This is equivalent to redeclaring: In this way, pointers between userspace and kernel space can be exchanged directly.

This mechanism was intended to efficiently address functions from the kernel space that would otherwise be in the userspace are limited. An example from those days is the UMSDOS file system. It maps a Unix file system to an underlying MS-DOS file system and accesses the MS-DOS file system driver via system functions. Since both UMSDOS and MS-DOS file system drivers are located in the kernel space, the set_fs () trick is used to “fool” the functions into coming out of userspace.

Variable instead of register The names of the functions set_fs (), get_fs () and Co. have remained the same – the FS register the kernel no longer uses it when it is called. From version 2.2 it was replaced by the platform-independent global variable addr_limit, the value of which shows the limit between user and kernel space. Everything below is userspace, everything above is kernel space. Compared to the FS register, addr_limit enables an address to be checked for validity much more easily. An arithmetic comparison with the variable value is sufficient to determine whether the address is located in the user space or in the kernel space.

The kernel function access_ok (), for example, checks an address against addr_limit for general purposes assign it to the user or kernel space and evaluate the access. The kernel now leaves the further access protection to the memory management unit (MMU) of the processor.