The Sunday before last, Linus Torvalds released the last release of the Linux kernel for this year. The new kernel 5. 10 receives Long Term Support (LTS) and will therefore receive patches for at least the next two years.

Currently kernel.org gives as “End of Life” (EOL) December 2022 at. As a rule, however, the maintenance period for LTS kernels is extended for up to five or six years – for example, the support period for issues 4. 19 and 5.4 in summer extended from two to six years.

First point release available, quick update advisable Linux 5. 10 exceeds its predecessor Linux 5.9 in the number of changesets, but lags slightly behind the current record holder Linux 5.8. “Record-breaking” (in terms of speed), however, is not 24 hours after the release of 5. 10 postponed first point release. Linux 5. 10 Greg Kroah-Hartman released 1 because of two errors that affected the storage system and thus a critical component .

The first fix contained in 5. . 1 attempts to repair the Device Mapper back: Originally an attempt was made to fix problems with the upper limit of the RAID DISCARD for RAID 1 and RAID 10. The effects of this unsuccessful attempt at correction have not yet been documented. The commit to the fix only contains the comment: “It causes problems :(.”

The second fix in 5. 10. 1 concerns the MD (Multiple Devices) code: In 5. 10 without the fix When mounting RAID6 setups, considerable problems and data loss can occur. Users of 5. 10 should therefore quickly switch to 5. 10. 1. Change. Additional corrections or new features include 5. 10. 1 not.

Freshly moved in: ARM Memory Tagging Extension With Linux 5. 10 the “ARMv8.5 Memory Tagging Extension” (ARMv8.5 MTE) keeps on ARM 64 Entry into the kernel. It appends a key to the pointer in order to automatically mark and recognize the (process) affiliation of a pointer This is intended to make code safer in the future and, in particular, to make life more difficult for attackers tick.

The ARM 64 architecture is for 64 – Bit pointer designed. Systems currently only use 48 bits or 52 bits, provided the “Large Address Option “is enabled. There is currently (still) no need to use all available 64 bits. In addition, ARM processors have a special feature that allows the top byte of a virtual address to be ignored (top byte ignore). Therefore, various extensions for these unused bits were created. A prominent representative is the “ARM Pointer Authentication”, which uses the cryptographic key in the top byte to authenticate pointers. With MTE there is now an extension in Linux.

The MTE uses the lower nibble (the lower four bits) of the upper byte of the virtual address. A marking can thus be assigned to one or more memory areas. If a pointer is dereferenced, the system compares the marking of the pointer with that of the memory area to which the pointer points. If the two markings are not identical, the CPU triggers a so-called trap: Unauthorized access is prevented.

MTE in action Four bits do not appear much, they can “only” manage 16 markings. In practice, this is usually sufficient to implement effective protective functions. With memory management routines such as malloc () and free (), protection mechanisms can be added to existing applications in a simple manner. For example, use-after-free bugs and buffer overflow attacks can be prevented or at least made more difficult. malloc () sets appropriate markings and tries to mark different stack frames differently at least by rotating the markers. The system thus seals them off from one another within an application.

If the system releases memory via free (), this free memory can be given a special label. This is explicitly marked as “released”. If the application wants to read this memory as a result of a bug or an attack, the markers of the pointer and the memory area do not match. The system triggers a trap as a result of a use-after-free situation.

Either the application itself or the CPU can manage the markings. The marks can be set to 16 – byte memory blocks. MTE is initially deactivated on all Linux systems. The extension can be activated from within the application via the PROT_MTE flag of mmap () or via mprotect (); a corresponding ARM 64 CPU required. PROT_MTE is only valid on anonymous memory. File-backed memory is not supported.

MTE is currently limited to the user space. The kernel itself does not yet use the feature. Support for the kernel space is planned for Linux 5. 11. Incidentally, MTE does not conflict with “ARM Pointer Authentication”. Although both extensions use the upper byte of the virtual address, both can be used at the same time. The four bits that MTE “digs up” from the upper byte shorten the cryptographic signatures of the pointer authentication. In principle, however, it can also work with the shortened signatures.