Notices by Jann Horn (jann@infosec.exchange)

huh, systemd-run is really neat, you can do stuff like:
$ systemd-run --user -S -p MemoryHigh=1000M -p MemoryMax=1100M
and get a shell inside which you can't use more than around 1G of RAM (but can use more swap)?

@whitequark what would bypassing ELF loading mean? pretty much the only elf loading the kernel does for a static binary is to map its memory ranges into an address space and then run it starting at the entry point...

@whitequark ah yes the vdso section is just a VMA with a custom page fault handler that inserts PTEs pointing to an in-kernel buffer on demand (and vvar is basically like that, too).
but ELF loading in the kernel isn't really all that complicated either, you basically go through an array of "please map this range to this location"...

@whitequark why is the posix compatible application making direct system calls

@vbabka also note that the "user" and "sys" times together are way lower than the "real" time

@vbabka oh no it's much worse (in terms of wall clock time) than just mutex contention, and doing the join before the open_sockets() call in main() would help somewhat but not all that much (because the open_sockets() call in the other thread would still be slow). and it's not the network subsystem's fault 😆

@vegard @vbabka that's not it. I'm pretty sure if these threads were runnable they would run, I tested this on a pretty much idle system

@vbabka @vegard nope! here's another example with the same performance issue:

@jandrusk 😛

@rgo closing the sockets would be one way to avoid the performance hit, yes; but can you also avoid the performance hit while opening that many sockets and keeping them open?
(sorry, I guess it's not a great example)

Linux kernel quiz: Why is this program so slow and takes around 50ms to run?
What line do you have to add to make it run in ~3ms instead without interfering with what this program does?

@jmorris @brauner Christian is joking about how I only learned about this feature because I looked at a patch that intended to use MSG_OOB as part of the new core dumping mechanism

I landed an LLVM change today that plumbs LLVM's existing !heapallocsite metadata into DWARF: https://github.com/llvm/llvm-project/commit/3f0c180ca07faf536d2ae0d69ec044fcd5a78716

This associates allocator call sites (in particular calls to C++ new) with DWARF type information; see the corresponding DWARF standard enhancement proposal, which has landed in the DWARF 6 Working Draft, and Microsoft's prior work that this is based on.

If you have C++ code that allocates heap objects with operator new and use a memory allocator that records the addresses from which it is called, this can be used by debugging/profiling tools to determine the types of heap allocations at runtime.

(LLVM does not yet support this for C-style malloc() calls yet though.)

I found a Linux kernel security bug (in AF_UNIX) and decided to write a kernel exploit for it that can go straight from "attacker can run arbitrary native code in a seccomp-sandboxed Chrome renderer" to kernel compromise:
https://googleprojectzero.blogspot.com/2025/08/from-chrome-renderer-code-exec-to-kernel.html

This post includes fun things like:

• a nice semi-arbitrary read primitive combined with an annoying write primitive
• slowing down usercopy without FUSE or userfaultfd
• CONFIG_RANDOMIZE_KSTACK_OFFSET as an exploitation aid
• a rarely-used kernel feature that Chrome doesn't need but is reachable in the Chrome sandbox
• sched_getcpu() usable inside Chrome renderers despite getcpu being blocked by seccomp (thanks to vDSO)

@brauner new feature work is one of the best ways to find bugs in existing code, I think :D

@dysfun @whitequark why is this a problem? as long as you have virtual memory, you pay something like up to 4093 bytes of data memory more than you need, plus some inefficiency of TLBs and page tables?

@whitequark compiler function attribute that teaches the compiler to lazily copy the stack after setjmp() has been called, so you basically have one active stack pointer and one stack pointer for saving old stack contents, and every callee of such a function, immediately after the call returns, backs up the current state of the now-active frame into memory referenced by the setjmp buffer

Pretty far up the list of things I find terrible about Linux development is how emailed patches often have no clear machine-readably-specified commit they should apply to which is available in git - so it takes some manual effort to figure out how to locally apply them so that I can look at the entire codebase with the patches applied.

Looking at a complex patch series with just 3 lines of context would be a really bad idea...

@whitequark is the GPU part of a CPU that enforces a combined TDP limit or are those things completely separate?

@whitequark does one of the two implementations involve more thread switches, where you have lots of "thread A wakes thread B, then thread A goes to sleep"? AFAIK the kernel already can't handle those particularly well (https://youtu.be/KXuZi9aeGTw?t=611), and I imagine adding more noise to the scheduler could make things worse?