@robertgraham I also wonder, naively: just how far a deliberate industry ask & a modest investment towards this major requirement would go in shaping what's taught in schools? Perhaps it's the tragedy of no perceived or articulated demand resulting in no supply.
Webp, now Brotli, recently introduced complex formats that eschewed formal mechanized definition and code generation in favor of hand-crafted imperative implementations. Billed as "modern", backed by supposedly superior development processes. Turned out as usual.
@robertgraham Indeed, the bit fiddling is exactly why & where formal methods matter the most. I say the bottom-up, from-the-binary-upward formal methods are the absolute bedrock for the rest. At least if you ask me :)
@robertgraham I agree that the failure pattern here is worth at least a few papers rather than a tweet, but I'd argue that it goes further than the code flaws. These requirements can and should've been formalized, given the intended scale--and the likely development costs, too.
"Your browser extensions or network settings have blocked the security verification process required by [a news website] To resolve this, [turn off all defensive filters]". -- No thank you. I hope your news are worth what you're paying to protect them from readers like me.
After months of getting things done w/ Claude Code, I've spent ~5 days programming by hand in Lean and a liquid typed language and it's…SO GREAT? I love living in a world where I can get 1000s of mindless LOC in a minute, but also spend an hour on 10 gorgeous handcrafted lines.
In the history of nuclear weapons safety, there was a debate between the military and the scientists at Sandia National Labs about whether traditional analog electronics were safe enough to control detonation. The labs demonstrated that in the case of a fire, the circuit boards could short and cause safety mechanisms to fail.
This prompted the development of "strong links" in Enhanced Nuclear Detonation Safety (ENDS). They were designed such that it was physically impossible to activate from random electricity, fire, or a physical crash. They could only activate by a complex and unique "intent" signal that cannot possibly be produced by natural events.
We are having a similar debate now around AI safety. The solution is to contain agents using signals that they cannot possibly produce.
More history around this by @SteveBellovin :
https://t.co/8L2G0dyTVD
One more Phrack 73 leak for you!
Blueboxing Myths and Feelings: a nostalgic dive into phone phreaking’s golden age.
https://t.co/1BKEANXmEi
by @hackerschoice and @GammaTHC
Thrilled that our paper "Proof Repair and (Co)algebra Equivalences" with Trey Plante, Eric Paul, Cosmo Viola, and Alex Kavvos was (conditionally) accepted to POPL! Amazing work by my students, and wonderful collaboration with Alex.
@halvarflake I find this most amazing, possibly a "peak tech debt" moment. Thinking, e.g., of how hard it was to get disassembly to recompile back to the exact same bytes---until it wasn't, as @mahal0z recently showed.
@caballerobrah@JustDeezGuy ROP is definitely a part of it, since its discovery in late 1990s-early 2000s by the hacker community and the key examples published in Bugtraq & Phrack. Hovav Shacham broke through to its academic recognition with the name of ROP and its math description in 2007. So it goes :)
Check out my latest blogpost.
"Shiva modules for detecting advanced persistent threats in Linux: Shiva vs. Saruman": https://t.co/lUoysAUMxS
The other day I released an updated version of Saruman for anti-forensics executable injection. This is essentially an APT (Advanced persistent threat) tool for stealthy injection of a program into a remote process. Very helpful for the offensive side, giving them a good way to hide their processes without needing a kernel rootkit.
But what about the defensive side? Today I release a threat detection module for detecting Saruman thread injection. This threat detection engine was designed as a Shiva module in less than one day, and is a great example of how Linux threat detection and exploit mitigation monitors can be rapidly designed and installed with Shiva.
@robertgraham This story needs to be repeated till it is textbook material. Not just for the sake of history, but for the sake of understanding the ways and value of software composition. "See, children, in the dark ages before formal methods good engineers had to do all this" :)
Let me tell you how I delayed WinXP SP2 for a month.
My software (BlackICE) was on the list of software that had to work. When they made major changes to the kernel network stack, my software broke.
They grabbed their reverse engineers to figure out why. What they discovered was that my software doing something evil, patching the kernel's network stack when our software was loaded. That's tricky on a multi-CPU system with warring instruction/data caches. We wrote a patent on how to do it reliably without crashing the system.
We searched through the kernel to find the location we needed to patch, looking for a certain pattern of bytes. They changed the network stack so that thing we were patching no longer existed.
So to make our software work, the inserted that pattern back into the kernel. As packets arrived, the new function would jump to that pattern, and then after, jump right back. This way, we could find the pattern and patch it -- and thereby patch the intended function.
Some Microsoft lawyers wanted to sue us for violating the software license agreement, which forbids reverse engineering, which we had to do in order to patch the kernel at runtime.
Cooler heads prevailed.
The point is our software did an ugly hack in order to work, and then Microsoft did an even crazier, uglier hack so that we'd keep working.
For years after, when meeting Microsoft engineers at conferences, they'd love to yell at me.
When Vista came along, they added signing of kernel models, putting an end to such nonsense, but also providing a real documented API we could use.