New LWN Articles About Linux and Vim
-
Kernel Space
-
LWN ☛ Page-table hardening with memory protection keys
Attacks on the kernel can take many forms; one popular exploitation path is to find a way to overwrite some memory with attacker-supplied data. If the right memory can be targeted, one well-targeted stray write is all that is needed to take control of the system. Since the system's page tables regulate access to memory, they are an attractive target for this type of attack. This patch set from Kevin Brodsky is an attempt to protect page tables (and, eventually, other data structures) using the "memory protection keys" feature provided by a number of CPU architectures.
Memory protection keys are an additional access-permission mechanism that is layered on top of the permissions implemented in the page tables. Memory can be partitioned into a relatively small number (eight or 16, typically) of domains (or "keys"). A key, in the sense used here, is simply a small integer value that has a set of memory-access permissions associated with it. Each page has an assigned key that can be used to impose additional access restrictions. Memory that is nominally writable cannot be written if its key denies that access. The permissions associated with a key can be changed quickly and affect all pages marked with that key; as a result, large swaths of memory can be quickly made accessible or inaccessible at any time.
Changing the permissions associated with a key is an unprivileged operation. Memory protection keys, thus, cannot protect against attackers who are able to execute arbitrary code. They can, though, be useful to protect against unintended access. Critical data can be write-protected using a key, with that key's permissions being briefly changed only when that data must be written. An attacker attempting to overwrite the same data, perhaps through exploitation of a use-after-free vulnerability, will be blocked, making the system that much harder to compromise. Similarly, memory containing sensitive data (cryptographic keys, for example) can be assigned a key that, most of the time, allows no access at all, reducing the likelihood that this data will be leaked to an attacker.
-
LWN ☛ Modifying another process's system calls
The ptrace() system call allows a suitably privileged process to modify another in a large number of ways. Among other things, ptrace() can intercept system calls and make changes to them, but such operations can be fiddly and architecture-dependent. This patch series from Dmitry Levin seeks to improve that situation by adding a new ptrace() operation to make changes to another process's system calls in an architecture-independent manner.
ptrace() has, since the 5.3 release in 2019, supported an operation, PTRACE_GET_SYSCALL_INFO, that can be used when the traced process has been stopped at a system call. It is used by, for example, the strace utility to obtain information about the system calls made by a process of interest. The addition of this operation made life easier for programs like strace which, previously, had needed special code to handle the unique way in which each architecture manages system-call arguments and return values. Now, the same ptrace() call works on all architectures supported by Linux.
System calls can be intercepted — and information gathered — at three different points: on system-call entry, on the return to user space after the system call completes, or when a seccomp() trace rule is executed. The information available at each point varies; on entry, for example, the system-call number and arguments are available. On exit, instead, PTRACE_GET_SYSCALL_INFO will provide the return value from the executed system call. This information comes back in the ptrace_syscall_info structure; the ptrace() manual page describes each of the returned fields.
-
-
Applications
-
LWN ☛ The state of Vim
The death of Bram Moolenaar, Vim founder and benevolent dictator for life (BDFL), in 2023 sent a shock through the community, and raised concern about the future of the project. At VimConf 2024 in November, current Vim maintainer Christian Brabandt delivered a keynote on ""the new Vim project"" that detailed how the community has reorganized itself to continue maintaining Vim and what the future looks like.
[...]
He stressed that maintaining Vim is not just about the source code. There are quite a few other things to be managed, such as the Vim web site, FTP server, security disclosures, Vim communities on other sites such as Reddit and Stack Exchange, and more.
Vim's site needed work. The design, and most of the code, had been unchanged for quite a while—until 2023, it was based on PHP 5. In recent times, there had been a few occasions where the web site was unstable, and so he started looking for a new host in 2024. The move involved an upgrade to PHP 8, for which some of the code had to be rewritten. Brabandt thanked Mark Schöchlin, who stepped up to take care of all this.
He acknowledged that the design has been pretty much unchanged since 2001, doesn't look modern, and can be scary to new users. There has been some work on redesigning it, but the first attempt hasn't been that successful. He prioritizes consistency and does not wish to scare away longtime users.
-