Failfs is a pretty cool pseudo-filesystem where every path lookup fails. So if yu place a statically-linked process into failfs with ONLY pre-allocated file-descriptors at process birth, close down unneeded sockets and enforce a default-deny firewall discipline, compromised applications are effectively isolated and unable to access local files or spawn shells during an exploit. An attacker can NOT move adjacently from the exploited process to other parts of the system because to do so they'll need to navigate from root and that would fail since yu set root as failfs and you've got yourself a pure, isolated data-processing pipe that can only interact via the exact file descriptors it was given!!
Unfortunately, yu can't use dynamically-linked apps anyway since failfs would break absolute path resolution loading system libraries.
EDIT::
But I guess yu could put a statically linked app on the socket, wrap it in failfs and gave it proxy requests to a dynamically-linked app process if your app must use something like python.
Is it possible to load the dynamic libraries before fork()ing and somehow prevent the path lookup and library loading? This will open up new possibilities for hardened security models.
That's a fun idea but take python (very familiar)... It's very deeply dynamic and even if yu run imports at the top of your code yu still have many large libs with lazy code execution baked deep inside their internal functions so that assumes yu actually know what code paths the application will hit later. More importantly this goes in the opposite direction of Python's lazy imports thingy.. basically you've got a bomb and yu wouldn't wanna do that. Also, imagine the startup time for large apps. I'd just put a statically-linked binary in front and proxy back to the dynamically-linked process if I can't rewrite the main app in something like Go or Rust.
You explicitly stated as such, I just want to emphasize it again: it only breaks dynamically linked libraries, which - from a stability point of view - is an antipattern anyway.
Almost always youre better off producing a bundle which has everything (excluding the runtime) included... Or just use better languages which categorically don't even have this scenario, eg golang, Java, rust, etc pp
ah, first sentence I thought yu was a typo. Second sentence I saw it I thought it might be a linux component of sorts. So it's not just a stylistic choice, it's actually harming my comprehension of what they're writing.
A process which is chrooted into failfs cannot open new files. It is limited to the set of filesystem file descriptors it already has open (presumably set up before the chroot or inherited into the process from some container runtime).
I'd love if chrooting would become easier. In particular a
requirement to have bash or a specific shell is annoying;
imo a simple REPL should suffice already there. I wrote one
that works years ago, need to look into what is all needed
for a chroot (I always used bash for this but I'd also want
to change to my own shell eventually).
We wanted capabilities[1]. Instead we get this over-complicated series of system calls with no design consistency that you have to use very carefully, else they can be bypassed (see the list of caveats on the failfs page).
I'd love to have one that randomly fails, so we could debug e.g. databases and other apps that are supposed to be resilient. I'd call it "havocfs". Doesn't corrupt data, just randomly fails reads/writes/etc. Some software is supposed to handle that gracefully. Would be a great test tool...
proposed by John Ericsson (Nix core contributor) for the idea of Null namespaces to make namespaces cheaper for when doing finegrained sandboxed builds.
Operating systems code can definitely afford runtime checking if it's not too expensive in terms of performance. The Linux kernel has a WARN_ON macro that does exactly this. The tradeoff is worth it in a lot of cases if you're exchanging a small amount of performance for greater debug-ability or security.
I think until something hardware-based like CHERI becomes widely deployed (which seems extremely unlikely in the near to mid term given), we're going to keep seeing VM escape CVEs pop up indefinitely.
Critical hardware bugs occur an order of magnitude less frequently than critical hypervisor/kernel bugs, which is why they always make the news. In general, they're also more difficult to exploit. We haven't seen any serious spectre or meltdown malware in the wild almost a decade later.
You seem to be arguing on the basis that people are throwing away the software security layers, when the discussion so far has been about hardening the software security layers even more with secure hardware.
This is the nirvana fallacy in action. Because you cannot imagine a world with perfect hardware, you think hardware that catches 99.9% of security bugs is worthless.
You seem to be discarding budget problems. Yes you can do a lot more things if you have unlimited budget, but that is rarely the case. So most solutions won't be implemented if they aren't also relatively inexpensive.
That's not necessarily true. Vibecoding a simple JSON -> YAML converter to translate a 2MB JSON is going to be much cheaper than including that JSON in a prompt and burning hundreds of thousands of tokens. Besides, there's lots of cases where the math simply favors a bigger one-time cost rather than paying fees in perpetuity.
Even today, an advanced AI model will realize exactly what you said, and generate a script and run it behind your back to save the costs and ensure correctness. To me, that's still using the agent directly, not vibe coding. No app gets developed in the process, and if the agent doesn't tell you, you won't even know any coding took place.
With the caveat that literal today's models are not allowed to run code themselves but instead give you the code in the chat window and ask you to run it yourself for security and safety reasons. But the capability is there.
Right, which makes the one-shot task cost the same as the permanent solution in that case. So if you wanted to do this task even twice, you would still be better off creating the tool once and just using it. Imagine if proof assistants like Lean didn't exist. Research with AI would get a whole lot more expensive if it had to re-create Lean every single time you asked it to prove something.
If you want to do literally the exact same task in literally the exact same configuration and ideally the exact same input data, then yes, it costs the same. But that solution is as permanent as it is useless.
A tool for generating a report for September 2026 is no more expensive than an agent generating a report for September 2026. But that tool is useless for you in October 2026. You'll need to generate a whole new tool for October 2026, and generating 2 tools costs as much as generating 2 reports so you're not saving anything.
Making a tool that can generate a report for any single month can easily cost 10 times more than a single report, entirely due to the extra code flow analysis required to extract the right variables in the right places. And that's without any UI. If you want UI that's another several times more tokens because UI is hard. Also it will suck compared to a simple chat window where you can ask the assistant for anything and it will understand. If you want UI that's better than the chat, that alone costs you more than everything you spent so far.
All in all, your permanent solution starts paying for itself in about 4 to 6 years, assuming you never had to update how the report is generated in the meantime.
Or you could have a very simple, very cheap script that only gets run once then gets deleted (or even better, kept for future reference to make future report scripts even cheaper to generate).
Note that this is all in the hypothetical future where AI is actually capable of one shotting such a task. If it makes mistakes, then human-made apps are still the most cost-effective option and this whole discussion is moot.
Could you elaborate on what you mean by "don't interact with hardware much anymore"? If you compare modern drivers with similar ones from 20 years ago, for example, you'll find the modern ones tend to be quite a bit more complex.
No directly anyway, for the OS it's all abstractions and isolation. There was a time when the OS could basically see and control everything, but now there are subsystems all over the place with their own memory, their own software, all outside of the control of the OS. CSME runs while the computer is powered off.
I really miss the customization that older laptops offered, especially the socketed CPUs. I remember putting a i7-3840QM in my T430 and having it shut down due to overheating every few minutes to the point where I had to install the heat sink from the GPU model. Was fun tinkering around with it and I wish modern laptops had a similar level of hackability.
I want to love the frameworks but the modifiable ports being a slot-in usbc dongle feels like such a cheap hack. Last I checked, the only available Ethernet module still sticks out of the case like a Lego brick
Yeah, Framework seems to fit that niche well. Only thing is that Framework isn't a tech giant like Lenovo so I imagine it would be more difficult to source replacement parts.
When I was shopping for that same CPU a couple of years ago for my T530, the cheapest way I found to get one to my door was to buy it already-installed in the bottom-half of a whole 'nother T530 -- with the nVidia upgrade (which I already had).
I thought it was pretty amusing to get the CPU and a complete pile of spare guts for less than the price of the CPU by itself.
Hah I'm doing this with some models of that same era judging by the CPU you cited. I had frankensteined one laptop from like the best parts out of three I had from that era, got xubuntu on it, running fine-ish but the Wi-Fi antenna ran through the on-board display chassis, which was destroyed. Took off the top clamshell, was gonna put ether in it and use as a desktop, but oops! The clip holding ethernet cable fell out during disassembly! No prob, pop it back open, oops! One of the screws holding the mobo is stripped! (Also, wife goes into labor while everything disassembled) No sweat, get something from ace to extract. I think I ended up throwing it back together and not testing?
Forgot about it for a couple years, wanted to put opnsense on it and see if I could replace stock equipment leased from ISP, nope. No display.
Fun to a point but probably should just spring for a used thinclient at this point, but prices are scary and I hate letting all this hw go to waste
Worth noting the gap between floating point vs integer division isn't that bad on newer CPUs these days. On Zen5, for instance, DIVSD has a latency of 13 cycles vs 16 cycles for DIV.
