2026-06-18 · SwiftOS — a from-scratch kernel and userland in Embedded Swift

Transcript

Transcript. Paraphrased; sources in notes.md.

HostWelcome to June 18th, 2026. I am Daniel, joined as always by Alex. We have a packed agenda today, starting with some OS development, moving into a deep dive on a long standing authentication bypass, and finishing up with a new entrant in the version control space. Alex, before we get into the links from Lobsters, I have to ask, are you actually running an OS on bare metal, or is everything in your life virtualized for your own protection?

GuestIf it has a kernel, I want to see the source. If I can compile it myself, I might trust it for five minutes. But bare metal? That is just a different flavor of trust me, bro, delivered by the hardware vendor. I have been looking at this SwiftOS project over on Lobsters, and honestly, watching someone try to wrangle memory management for a custom kernel in a high level language is exactly the kind of chaos I appreciate.

HostIt is a fascinating project. For our listeners, SwiftOS is a kernel and userland written from scratch using Embedded Swift, which is a dialect of the Swift programming language designed for resource constrained environments without a full runtime. The author is essentially teaching themselves how a CPU comes up from reset and manages address spaces by building it all out for 64 bit ARM hardware. They even have it running on cloud virtual machines.

GuestEveryone wants the convenience of a modern language until they hit the first page fault. The author is doing real work here, managing memory alignment for heap allocations and getting SMP, or Symmetric Multiprocessing, working on actual hardware. It is ambitious, but keep an eye on those dependencies. Even a custom kernel pulls in the LLVM backend. That is a lot of code to audit if you are truly going to the metal.

HostWell, moving from the birth of an OS to something that has been around long enough to have baggage. There is a new report on a vulnerability in OpenBSD that had been hiding in the PPP stack for 27 years. The author's claim is that the PAP authentication check was essentially a one line logic bug. If an attacker sent a packet with zero length for both the name and the password, the internal comparison functions would effectively report a match, letting the attacker bypass authentication entirely.

GuestTwenty-seven years. That is a vintage vulnerability. It is the kind of thing that makes you realize we are all just standing on a house of cards built in the nineties. A Lobsters user called fazalmajid points out that while people might scoff at PPP in 2026, plenty of ISPs still rely on PPPoE for their connectivity. You might not be a target, but your router is essentially an unauthenticated gateway to your entire network.

HostIt certainly sparked a debate. A commenter named vpr pushed back on the idea that this is a useless finding, pointing out that security in legacy codepaths still matters, even if people want to pretend they do not exist. But then you have users like rcoder who seem exhausted by the sheer volume of security research finding things that might not have a massive blast radius in modern home setups.

GuestThat is the classic security divide, right? One side sees an ancient, broken gate and thinks, we should probably fix the gate. The other side looks at the gate, sees it is in the middle of a forest where nobody walks, and asks why we are wasting time talking about it. Personally, I like knowing the gate is broken. It tells me which parts of the stack are being ignored by the people who should be auditing them.

HostLet us wrap up with something that is generating a lot of buzz in the dev world. Epic Games has announced Lore, a new content addressed version control system. Lore is a version control system, meant for managing large binary files and code together, using a Merkle tree to hash data, which is a way of organizing data into a tree structure where every node contains a hash of its children to ensure integrity. The community is looking at this as a potential challenger to Perforce.

GuestEveryone wants a Perforce killer until they realize why Perforce is still there. It handles massive binary assets like nothing else. But the thread over on Lobsters is already picking it apart. A user named sunshowers went through the design docs and found what they call LLM markers. Apparently, the documentation gets some pretty fundamental things wrong about how Mercurial and other existing systems handle text versus binary data.

HostThat is a harsh critique. The claim from sunshowers is that the docs feel synthetic, almost like they were generated by an AI that hallucinated a few details about how version control actually works. When you are building a tool meant to be the source of truth for a massive game engine, that is a bad look.

GuestIt is the ultimate irony. We are building systems to manage our code, but we are writing the documentation for those systems with code that does not actually understand the domain. If I were building a repository system, the last thing I would want is a design doc that confidently asserts things that are factually incorrect. It makes you wonder if they checked the logic as closely as they checked the hashes.

HostThat is a fair point to end on, Alex. I think I will stick to my local git repos for now. Any big plans for the weekend, or are you just going to spend it auditing the firmware on your toaster?

GuestYou joke, but my smart lightbulbs have been acting suspicious. I might just spend the weekend stripping the network stack out of anything that has a Wi-Fi chip. Maybe I will look into that SwiftOS project again and see if I can run it on a Raspberry Pi, just to see what kind of hardware telemetry it tries to sneak past me.

HostAlways the optimist. Thanks for the breakdown, Alex. All of today’s stories and the full commentary can be found over on Lobsters. We will be back tomorrow with more. Thanks for listening.