human borrow checker (but logic bugs are best bugs).
works at Google Project Zero.
The density of logic bugs (compared to memory corruption bugs) goes down as the privilege differential between attacker context and target context goes up.
| homepage | https://thejh.net |
randomly wondering: on x86, could you use INVLPGB or RAR to make all other processors go through a memory barrier, or at least something like a memory barrier limited to a specific virtual memory location? (and would it be faster than a broadcast IPI?)
A TLB invalidation has to ensure that writes to the location being invalidated become visible before the TLB invalidation completes, so as long as these mechanisms are instruction-serializing, I guess it should be possible?
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?
Matt Linton 
user@debian12:~/test$ cat > slow.c
#include <pthread.h>
#include <unistd.h>
#include <err.h>
#include <sys/socket.h>
static void open_sockets(void) {
for (int i=0; i<256; i++) {
int sock = socket(AF_INET, SOCK_STREAM, 0);
if (sock == -1)
err(1, "socket");
}
}
static void *thread_fn(void *dummy) {
open_sockets();
return NULL;
}
int main(void) {
pthread_t thread;
if (pthread_create(&thread, NULL, thread_fn, NULL))
errx(1, "pthread_create");
open_sockets();
if (pthread_join(thread, NULL))
errx(1, "pthread_join");
return 0;
}
user@debian12:~/test$ gcc -O2 -o slow slow.c -Wall
user@debian12:~/test$ time ./slow
real 0m0.041s
user 0m0.003s
sys 0m0.000s
user@debian12:~/test$ time ./slow
real 0m0.053s
user 0m0.003s
sys 0m0.000s
user@debian12:~/test$
Digging into the drive in my NAS that faulted, I'm reminded that magnetic hard drives are preposterously magical technology.
Case in point, using Seagate's tools I can get the drive to tell me how much it's adjusted the fly height of each of its 18 heads over the drive's lifetime, to compensate for wear and stuff. The drive provides these numbers in _thousandths of an angstrom_, or 0.1 _picometers_.
For reference, one helium atom is about 49 picometers in diameter. The drive is adjusting each head individually, in increments of a fraction of a helium atom, to keep them at the right height. I can't find numbers of modern drives, but what I can find for circa ten years ago is that the overall fly height had been reduced to under a nanometer, so the drive head is hovering on a gas bearing that's maybe 10-20 helium atoms thick, and adjusting its position even more minutely than that
This is _extremely_ silly. You can buy a box that contains not just one, but several copies of a mechanism capable of sub-picometer altitude control, and store shitposts on it! That's wild.
Anyway my sad drive apparently looks like it had a head impact, not a full crash but I guess clipped a tiny peak on the platter and splattered a couple thousand sectors. Yow. But I'm told this isn't too uncommon, and isn't the end of the world? Which is, again, just ludicrous to think of. The drive head that appears to have bonked something has adjusted its altitude by almost 0.5 picometers in its 2.5 years in service. Is that a lot? I have no idea!
Aside from having to resilver the array and the reallocated sector count taking a big spike, the drive is now fine and both SMART and vendor data say it could eat this many sectors again 8-9 times before hitting the warranty RMA threshold. Which is very silly. But I guess I should keep an eye on it.
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:
Dave AndersonCONFIG_RANDOMIZE_KSTACK_OFFSET as an exploitation aidsched_getcpu() usable inside Chrome renderers despite getcpu being blocked by seccomp (thanks to vDSO)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.)
