staticassertion

It's very easy to just instruct the LLM to build using isolated crates, to maintain boundaries, focus on "ports and adapters", etc, and not run into this - in my experience.

I haven't had any issues with this getting out of hand on >10KLOC vibed rust codebases.

He's tweeting his experiences. Calling this "sprinting" and "evangelizing" is just rhetoric. Posting about a project you're working on is hardly amateurish.

io-uring is in a different league imo. I'd say that it's second only to user namespaces in terms of attack surface.

That said, putting stuff in a docker container is kinda a light lift that cuts a bunch of attack surface.

io-uring is a security nightmare. Constant privescs and a powerful primitive for syscall smuggling. Worth considering disabling it outright (already the case for most containers afaik).

I'm not and I'm doing it right now.

Okay, so what is Cloudflare's "DVD" equivalent? And what about AI necessitates smaller teams?

You don't need unprivileged user namespaces for this one if you're in a position to get the target kernel module loaded. But yeah, user namespaces are basically the single most significant privesc path in the kernel, maybe io-uring is second. Disabling both (or very carefully deciding what can use them) is one of the best ways to reduce your attack surface.

I don't have any guides but you can determine which kernel modules are already loaded in your system and then just compile those in and block module loading.

Otherwise, shove everything into a container, ideally gvisor, and you've reduced attack surface by a large chunk again via seccomp.

An exploit was already published.

Trivially. Kernel modules autoload through various unprivileged mechanisms.

> The old “quiet patch before disclosure” model may simply not work anymore in the LLM era.

It never did. Trawling the Linux commit history is a tried and true method for finding n-days.

Spender didn't publish any exploit afaik

The commit for the fix was public. Someone noticed. An exploit was published.

I assume because the rxrpc module is not loaded / provided and because unprivileged user namespaces are not allowed, which should be sufficient to mitigate. Curious if someone else has more details though.

We already find bugs constantly in Linux and they go unaddressed, no one even keeps up with syzkaller reports lol

AI is neat because it's higher signal but yeah no, we're not getting anywhere close to "safe linux", AI or not.

Larger target.

New vulns are introduced to Linux every day. Fuzzers trigger every single day on Linux. No, nothing will improve here from AI.

Nothing about fedramp requires that you enable any of the features you're talking about. Linking to a public preview of an Azure product that doesn't even run with enforcement on is not great supporting evidence.

Syscalls and kernel module loading can both be logged, I assume that's sufficient here.

lol no one does that (edit: or, rather, that is extremely uncommon, even in "serious" environments, for a ton of reasons).

Sort of obvious, like dietary differences? They attempt a specific vegan control, but what if you aren't vegan but also dislike the taste of meat? What if you don't have a diagnosed health condition, but have a family history so you avoid eggs?

This isn't that complicated. Observational studies just have these weaknesses. We're past the point of observation here, as I said, and it's time to try intervention testing.

Maybe a sort of interesting study but it's observational and full of speculative mechanistic fluff, and I don't think it controls well enough. We're kinda past the point of egg studies, just study the mechanisms speculated on in an intervention study, right?

Ha, no, I did not write that crate. I think my use of this username probably predates rust, certainly that crate.

Postfix macros had some very tricky issues and it would have delayed things a lot to figure out the right resolution.

I was a proponent of the postfix macro solution. `.await!` or `.await!()`, essentially. The idea was that this could be generalized, it was closer to existing syntax, etc.

I was worried about features that I still don't love like `.match` etc (I'm more open to these now).

Post-fix macros would have been very complex. Scoping alone is complex.

`.await` kinda just works. It does everything you want and the one cost is that it looks like a property access but it isn't. A trivial cost in retrospect that I was a huge baby about, and I'll always feel bad about that.

I'm not prominent but I disagreed with it at the time and I was wrong.

I assume he means deterministic here, meaning that the translation program always produces the same output for a given input.

But none of these properties are what let you perform a successful port. The port is going to rely entirely on oracle testing.

Why does the deterministic nature matter? The interesting part is having oracle tests, not determinism. If someone is deterministic and wrong you use oracle tests to catch that.

> a security bug in them that one time?

More than one time.

> a cryptographic performance enhancement feature

It's very rarely used.

> Did we blacklist OpenSSL's binaries after Heartbleed?

No, but lots of companies have since migrated away. OpenSSL was harder to move away from because there weren't as obvious drop-in replacements. Blocking a syscall that you never actually used is simple and effective.

Containers are a security boundary, yes.

> A CVE next week that allows corruption of host state that affects eg every VM under a particular hypervisor will be no less damaging than this CVE is to containers

Yeah this almost never happens though whereas Linux privesc is 10x a day.

These sorts of vulns are extremely common on Linux. This one is making the rounds for various reasons but it's a good justification for a migration away from containers if your threat model is concerned about it.

MicroVMs have much lower attack surface and you can even toss a container into one if you'd like.

Or use gvisor, which mitigates this vulnerability.

The reason is that it's very rarely used and has a history of issues.