All posts by corbet

[$] I/O scheduling for single-queue devices

Post Syndicated from corbet original https://lwn.net/Articles/767987/rss

Block I/O performance can be one of the determining factors for the
performance of a system as a whole, especially on systems with slower
drives. The need to optimize I/O patterns has led to the development of a
long series of I/O schedulers over the years; one of the most recent of
those is BFQ, which was merged during the
4.12 development cycle. BFQ incorporates an impressive set of heuristics
designed to improve interactive performance, but it has, thus far, seen
relatively little uptake in deployed systems. An attempt to make BFQ the
default I/O scheduler for some types of storage devices has raised some
interesting questions, though, on how such decisions should be made.

Tutanota, the First Encrypted Email Service with an App on F-Droid (Linux Journal)

Post Syndicated from corbet original https://lwn.net/Articles/768149/rss

Here’s a
Linux Journal article from one of the creators of the Tutanota
encrypted email client. “That’s why we decided to build Tutanota: a secure email service that is so easy to use, everyone can send confidential email, not only the tech-savvy. The entire encryption process runs locally on users’ devices, and it’s fully automated. The automatic encryption also enabled us to build fully encrypted email apps for Android and iOS.

Finally, end-to-end encrypted email is starting to become the standard: 58% of all email sent from Tutanota already are end-to-end encrypted, and the percentage is constantly rising.”

Control Flow Integrity in the Android kernel (Android Developers)

Post Syndicated from corbet original https://lwn.net/Articles/768094/rss

The Android Developers Blog describes
the control-flow integrity work that is shipping on the Pixel 3
handset. “LLVM’s CFI implementation adds a check before each
indirect branch to confirm that the target address points to a valid
function with a correct signature. This prevents an indirect branch from
jumping to an arbitrary code location and even limits the functions that
can be called. As C compilers do not enforce similar restrictions on
indirect branches, there were several CFI violations due to function type
declaration mismatches even in the core kernel that we have addressed in
our CFI patch sets for kernels 4.9 and 4.14.”

Gregg: bpftrace (DTrace 2.0) for Linux 2018

Post Syndicated from corbet original https://lwn.net/Articles/767956/rss

Brendan Gregg introduces
the bpftrace tracing tool. “bpftrace was created as an even
higher-level front end for custom ad-hoc tracing, and can serve a similar
role as DTrace. We’ve been adding bpftrace features as we need them, not
just because DTrace had them. I can think of over a dozen things that
DTrace can do that bpftrace currently cannot, including custom aggregation
printing, shell arguments, translators, sizeof(), speculative tracing, and
forced panics.”

Amit: How new-lines affect the Linux kernel performance

Post Syndicated from corbet original https://lwn.net/Articles/767884/rss

Nadav Amit decided to dig into why some small kernel functions were not
being inlined by GCC; the result is a detailed
investigation into how these things can go wrong. “Ignoring the
assembly shenanigans that this code uses, we can see that in practice it
generates a single ud2 instruction. However, the compiler considers this
code to be ‘big’ and consequently oftentimes does not inline functions that
use WARN() or similar functions.

The reason turns to be the newline characters (marked as ‘\n’ above). The
kernel compiler, GCC, is unaware to the code size that will be generated by
the inline assembly. It therefore tries to estimate its size based on
newline characters and statement separators (‘;’ on x86).”

[$] Some numbers from the 4.19 development cycle

Post Syndicated from corbet original https://lwn.net/Articles/767635/rss

The release of 4.19-rc6 on
September 30 is an indication that the 4.19 development cycle is
heading toward its conclusion. Naturally, that means it’s time to have a
look at where the contributions for this cycle came from. The upheavals
currently playing out
in the kernel community do not show at this level, but there are
some new faces to be seen in the top contributors this time around.

[$] New AT_ flags for restricting pathname lookup

Post Syndicated from corbet original https://lwn.net/Articles/767547/rss

System calls like openat()
have access to the entire filesystem —
or, at least, that part of the filesystem that exists in the current mount
namespace and which the caller has the
permission to access. There are times, though, when it is desirable to
reduce that access, usually for reasons of security; that has proved to be
especially true in many container use cases. A new patch
set from Aleksa Sarai has revived an old idea: provide a set of
AT_ flags that can be used to control the scope of a given
pathname lookup operation.

[$] Device-to-device memory-transfer offload with P2PDMA

Post Syndicated from corbet original https://lwn.net/Articles/767281/rss

One of the most common tasks carried out by device drivers is setting
up DMA operations for data transfers between main memory and the device. Often,
data read into memory from one device will be immediately written, unchanged,
to another device. Common examples include carrying the image between the
camera and screen on a mobile phone, or downloading files to be saved on a
disk. Those transfers have an impact on the CPU even if it does not use the
data directly, due to higher memory use and effects like
cache trashing. There are cases where it is possible to avoid usage of the
system memory completely, though. A patch set (posted by Logan Gunthorpe with
contributions by Christoph Hellwig and Steve Wise)
has been in the works for some time that addresses this case for PCI
devices using peer-to-peer (P2P) transfers, with a focus on offering an
offload option for the NVMe fabrics target subsystem.

[$] XFS, LSM, and low-level management APIs

Post Syndicated from corbet original https://lwn.net/Articles/767398/rss

The Linux Security Module (LSM) subsystem allows security
modules to hook into many low-level operations within the kernel; modules
can use those hooks to examine each requested operation and decide whether
it should be allowed to proceed or not. In theory, just about every
low-level operation is covered by an LSM hook; in practice, there are some
gaps. A discussion regarding one of those gaps — low-level
ioctl() operations on XFS filesystems — has revealed a thorny
problem and a significant difference of opinion on what the correct
solution is.

[$] OpenBSD’s unveil()

Post Syndicated from corbet original https://lwn.net/Articles/767137/rss

One of the key aspects of hardening the user-space side of an operating
system is to provide mechanisms for restricting which parts of the
filesystem hierarchy a given process can access. Linux has a number of
mechanisms of varying capability and complexity for this purpose, but other
kernels have taken a different approach. Over the last few months, OpenBSD
has inaugurated a new system call named unveil() for this
type of hardening that differs significantly from the mechanisms found in
Linux.

Nuitka 0.60 released

Post Syndicated from corbet original https://lwn.net/Articles/767122/rss

Nuitka is a compiler
for the Python 2.7 and 3.7 languages; version 0.6.0 is
now available. “This release adds massive improvements for optimization and a couple of bug fixes.

It also indicates reaching the mile stone of doing actual type inference,
even if only very limited.” At this point, the claim is that all
Python language features have been implemented, so the focus is shifting
toward optimization.