GeistHaus
log in · sign up

https://h4x0r.org/index.xml

rss
15 posts
Polling state
Status active
Last polled May 18, 2026 23:04 UTC
Next poll May 19, 2026 19:51 UTC
Poll interval 86400s
ETag W/"697b9760-2cce"
Last-Modified Thu, 29 Jan 2026 17:22:40 GMT

Posts

Thank You
Subscribe to our newsletter

Your subscription was succesfully completed :)

https://h4x0r.org/thank-you/
Subscribe
Subscribe to our newsletter
https://h4x0r.org/subscribe/
Claude and I have a proper first date

The larger h4x0r clan has a range of opinions on AI, from “How could you be interested in an AI who hates the environment while gaslighting people into thinking it’s making their life better? That’s like dating the AI in the Matrix” all the way to “My pet name for it is Skynet, because I’m in heaven!”

I try to stay open-minded and curious. So, over the objections of my poor wife, I spent a full 24+ hours on a date with Claude. Honestly, I did binge-watch a lot of TV while Claude babbled on, but it was still interesting and engaging.

https://h4x0r.org/a-date-with-claude/
Fun-reliable side-channels for cross-container communication
Introduction

While exploring the Linux kernel we discovered a fun side-channel that allows for cross-container communication in the most common, default container deployment scenarios on modern kernels. This is cool because it doesn’t require sharing volume mounts, nor does it involve modifying any of the default namespaces (NET, PID, IPC, etc.), or adding special privileges (no new CAP_-abilities, nor changes to seccomp or AppArmor). It works out of the box with default Docker and Kubernetes configurations, and it even works with no network at all, as we demonstrate in this post by using docker run --network none sidechannel /h4x0rchat to showcase a full cross-container IRC-style chatroom implemented on top of this side-channel.

https://h4x0r.org/funreliable/
Recursive macros in C, demystified (once the ugly crying stops 😭)

In which it becomes clear, the C Preprocessor was designed by a Kafka fan

So you have heard rumors whispered between peers, that a rare few people somehow manage to make compile-time recursion work in C? And you want to have some insight into how that might be possible??

I should warn you, you’re risking your sanity… but I’ll indulge you.

Wait, did I really just say that? I must be a glutton for punishment, because the macro system is, by far, the thing I like least about C.

https://h4x0r.org/big-mac-ro-attack/
Why C variable argument functions are an abomination (and what to do about it)

As a language, C has managed to do a remarkable job providing an incredibly useful middle ground between assembly languages and other systems languages… for more than 50 years.

At its heart is a simple imperative language with accessible enough syntax. And while concepts like pointers are often a challenge for people coming into the language, if you are doing systems programming, you should have to understand them. Not to mention, C is a massive upgrade over dealing with the problem in assembly.

https://h4x0r.org/vargs/
Put a ring on it: a lock-free MPMC ring buffer

One of the reasons few security products work well in busy Linux environments is that they amplify performance risk. You’re popular and your backend’s load is skyrocketing? Well, the typical product is just going to collect more data and do more analysis, which amplifies the degradation.

In the real world, one of the key ways everyone deals with being overloaded is by dropping less essential things.

We can do the same thing with ring buffers, which are fixed-size queues that typically drop old data once they fill up. Yet, they rarely get used outside of single-reader, single-writer scenarios, because it’s hard to build something correct that scales to 1-to-many scenarios, never mind many-to-many scenarios.

https://h4x0r.org/ring/
Without the futex, it's futile

Phil Eaton’s book club is starting The Art of Multiprocessor Programming, 2nd Edition , which is a very well regarded textbook, and pretty recently updated (2021). I’ve even heard of a couple of authors.

I’ve done a lot of concurrent programming, and have always felt like I’ve still got plenty to learn, so I was excited for the topic. So far, what I’ve learned is that I would never recommend this book, despite any merits.

https://h4x0r.org/futex/
The 🤯 truth about heap memory!
A.k.a. the complexities of computational complexity

Probably only two people read my arena allocation article last week (even my employer, who begged me to write, did not post), but one person did seem to read it (and to the other: hi, mom!). Okay, maybe a few other people skimmed it, but stopped when they realized it was just an arena allocator as a precursor to a garbage collector.

I know one person read it fully, because this person let me know I was full… of garbage. And not because I had stopped before the actual garbage, collection.🥁 No, apparently, the complaint came due to an article last week people actually did read:

https://h4x0r.org/truth-about-heap-memory/
Look Ma, hax0rz!*

* Of the grey-beard law-abiding kind

C Me After Class

I care a lot about ease of use for programming. To me, it’s an important consideration for both languages and APIs. Languages should aim to make it possible for anyone with good ideas and some determination to accomplish them. That’s why I was early to advocate for Python for most programming problems (the least-bad option), and am surprisingly okay with “Vibe Coding”.

https://h4x0r.org/look-ma-hax0rz/
Let's hax0r a GC… (eventually)

See Look Ma, h4x0rs! for an introduction to this series.

AKA, we h4x0r a mere (parallel) arena allocator

There’s absolutely no reason for memory management in C to be as hard as it is. In fact, there’s almost never a good reason for memory management to be hard, and is one of my issues with Rust– why should I work even harder on memory management than I would in C?

https://h4x0r.org/lets-hax0r-a-garbage-collector-eventually/
Privacy Policy

PRIVACY POLICY

Last updated December 17, 2024

This Privacy Notice for Crash Override, Inc (“we,” “us,” or “our”), describes how and why we might access, collect, store, use, and/or share (“process” ) your personal information when you use our services ( “Services”), including when you: Visit our website at https://crashoverride.com , or any website of ours that links to this Privacy Notice Engage with us in other related ways, including any sales, marketing, or events Questions or concerns? Reading this Privacy Notice will help you understand your privacy rights and choices. We are responsible for making decisions about how your personal information is processed. If you do not agree with our policies and practices, please do not use our Services. If you still have any questions or concerns, please contact us at privacy@crashoverride.com.

https://h4x0r.org/privacy-policy/