Language Selection

English French German Italian Portuguese Spanish

Kernel: LWN Articles (Outside Paywall Today), F2FS and BPF

Filed under
Linux
  • LSM stacking and the future

    The idea of stacking (or chaining) Linux security modules (LSMs) goes back 15 years (at least) at this point; progress has definitely been made along the way, especially in the last decade or so. It has been possible to stack "minor" LSMs with one major LSM (e.g. SELinux, Smack, or AppArmor) for some time, but mixing, say, SELinux and AppArmor in the same system has not been possible. Combining major security solutions may not seem like a truly important feature, but there is a use case where it is pretty clearly needed: containers. Longtime LSM stacker (and Smack maintainer) Casey Schaufler gave a presentation at the 2019 Linux Security Summit Europe to report on the status and plans for allowing arbitrary LSM stacking.

    LSMs allow adding more restrictions to Linux than those afforded by the traditional security policies. For the most part, those policies reflect the existing mechanisms, such as permissions bits on files. But there are also other security concerns, such as binding to a network socket, that are outside of the usual permissions, so mechanisms to restrict access to them have been added to the LSM interface.

  • Some near-term arm64 hardening patches

    The arm64 architecture is found at the core of many, if not most, mobile devices; that means that arm64 devices are destined to be the target of attackers worldwide. That has led to a high level of interest in technologies that can harden these systems. There are currently several such technologies, based in both hardware and software, that are being readied for the arm64 kernel; read on for a survey on what is coming.

  • Keeping memory contents secret

    One of the many responsibilities of the operating system is to help processes keep secrets from each other. Operating systems often fail in this regard, sometimes due to factors — such as hardware bugs and user-space vulnerabilities — that are beyond their direct control. It is thus unsurprising that there is an increasing level of interest in ways to improve the ability to keep data secret, perhaps even from the operating system itself. The MAP_EXCLUSIVE patch set from Mike Rapoport is one example of the work that is being done in this area; it also shows that the development community has not yet really begun to figure out how this type of feature should work.
    MAP_EXCLUSIVE is a new flag for the mmap() system call; its purpose is to request a region of memory that is mapped only for the calling process and inaccessible to anybody else, including the kernel. It is a part of a larger address-space isolation effort underway in the memory-management subsystem, most of which is based on the idea that unmapped memory is much harder for an attacker to access.

    Mapping a memory range with MAP_EXCLUSIVE has a number of effects. It automatically implies the MAP_LOCKED and MAP_POPULATE flags, meaning that the memory in question will be immediately faulted into RAM and locked there — it should never find its way to a swap area, for example. The MAP_PRIVATE and MAP_ANONYMOUS flags are required, and MAP_HUGETLB is not allowed. Pages that are mapped this way will not be copied if the process forks. They are also removed from the kernel's direct mapping — the linear mapping of all of physical memory — making them inaccessible to the kernel in most circumstances.

    The goal behind MAP_EXCLUSIVE seems to have support within the community, but the actual implementation has raised a number of questions about how this functionality should work. One area of concern is the removal of the pages from the direct mapping. The kernel uses huge pages for that mapping, since that gives a significant performance improvement through decreased translation lookaside buffer (TLB) pressure. Carving specific pages out of that mapping requires splitting the huge pages into normal pages, slowing things down for every process in the system. The splitting of the direct mapping in another context caused a 2% performance regression at Facebook, according to Alexei Starovoitov in October; that is not a cost that everybody is willing to pay.

    Elena Reshetova indicated that she has been working on similar functionality; rather than enhancing mmap(), her patch provides a new madvise() flag and requires that the secret areas be a multiple of the page size. Her version will eventually wipe any secret areas before returning the memory to general use in case the calling process doesn't do that.

  • F2FS File-System Gets More Fixes With Linux 5.5

    The Flash-Friendly File-System continues to be refined and with the forthcoming Linux 5.5 kernel are more improvements albeit largely bug fixes.

    F2FS in Linux 5.5 improves the in-place updating I/O flow, ensures no garbage collection for pinned files, avoids a needless data migration within the garbage collection code, fixes a potential memory leak, and has a number of other fixes.

  • Netflix: BPF is a new type of software we use to run Linux apps securely in the kernel

    There's growing interest in a new type of software for Linux machines called BPF, which allows the user to run a program in the kernel and enjoy "observability super powers", according to Brendan Gregg, a senior performance architect at Netflix.

    BPF isn't something an average computer user would know about or even use, but for network and software engineers it promises value. At Facebook, for example, engineers use BPF as part of a network load balancer.

    Facebook software engineer Alexei Starovoitov is credited with creating Extended BPF, which is now used in Android for collecting statistics from the kernel, monitoring, or debugging. And Google is using it as part of its Kernel Runtime Security Instrumentation to improve detection of security threat signals, such as a kernel module that loads and hides itself.

More in Tux Machines

Today in Techrights

Raspberry Pi 4 Benchmarked with 32-bit and 64-bit Debian OS

The first Raspberry Pi board with a 64-bit Arm processor was Raspberry Pi 3 Model B, and all new models including the latest Raspberry Pi 4 come with four Arm Cortex-A 64-bit cores. But in order to keep backward software compatibility with the original Raspberry Pi and Raspberry Pi 2, the Raspberry Pi foundation decided to keep provided 32-bit OS image, so nearly everybody is now running a 32-bit OS on 64-bit hardware, and Eben Upton famously claimed it did not matter. We already wrote that 64-bit Arm (Aarch64) boosted performance by 15 to 30% against 32-bit Arm (Aarch32) several years ago, but Matteo Croce decided to try it out himself on Raspberry Pi 4 board first running benchmarks on Raspbian 32-bit before switching to a lightweight version of Debian compiled as aarch64. Read more

How to Install TensorFlow on Ubuntu Linux Properly

Complete beginner’s guide that teaches you to install TensorFlow on Ubuntu in easy to follow steps. Read more

Meet FuryBSD: A New Desktop BSD Distribution

FuryBSD is a new BSD distribution based on FreeBSD and tweaked for desktops. Here's more information about this new project. Read more