Christine Lemmer-Webber1d ago

Significant raise of reports (on the Linux Kernel Mailing List) https://lwn.net/Articles/1065620/

Here's something I think we all will have to contend with, whether you're an AIgen enthusiast or not: attacking is easier than defending, and these things don't get tired and they *are* very good at finding exploits. None of us will be able to ignore that, and we will probably have to listen to real genuine reports from them, even if we reject AIgen input.

However, I don't think that's actually the right solution, and I don't think it's sustainable. 🧵

Significant raise of reports [LWN.net]

Show threadChristine Lemmer-Webber1d ago

The fact of the matter is, most vulnerabilities fall under extremely common patterns, with known solutions:

- Confused deputies: capability security can fix/contain this in many cases, more on that later
- Injection attacks: primarily caused by string templating, using structured templating also fixes this (quasiquote, functional combinators, etc)
- Memory vulnerabilities: solved by memory-safe languages, and yes that includes Rust, but it also includes Python, Scheme/Lisp, etc etc etc

There are other serious vulnerabilities, such as incorrectly written or used cryptography, and others from there, but my primary point is: most damage can be either avoided in the first place or contained (especially in terms of capability security for containment)

And... patching AIgen patches is going to get tough and tiring... (cotd...)

Show threadCassandrich
@cwebber Memory vulnerabilities are also drastically cut off (not entirely precluded, but far less likely) if, when using C, you reject any temptation to have complex object lifetimes and work as much as possible with long-lived, reserved-in-advance storage. The kernel is a horrible offender on getting this wrong.
Apr 2 at 2:05pmWeb
Show threadJérôme Petazzoni1d ago
@dalias do you know of any book/article/... that would explain or describe how to design a general purpose kernel with that in mind? (I wonder what things like file descriptors, device handlers, etc would look like there!)
Show threadCassandrich1d ago
@jpetazzo Sadly no. A lot of this is personal experience and stuff I'd *like* to write if I could be motivated to do so.. 🙃
Show threadLaurent Bercot1d ago

@dalias For complex objects, the main problem I've identified is the coupling of storage and structure. When storing data in the structure, it's easy to free when you shouldn't and vice-versa.

Decoupling storage from structure is the best practice I've learned over the past 15 years, and it's applicable even when you can't reserve your storage in advance.

Storage provisioning is useful, but it's mostly useful with another safety aspect: failing as early as possible and avoiding resource allocation in critical moments.

Show threadwitch_t *navi1d ago
@ska @dalias

"decouple storage from structure" is one of the best things but when i first started trying to think about it more, it was hard to wrap my head around how to design things to work like that

i feel like a page of example apis or a book or smth would be very helpful for new folks not familiar with it
Show threadLaurent Bercot1d ago

@navi @dalias Yeah, the way most people write C with pointers everywhere - because that's what they've been taught - isn't very compatible with that. Again, it comes down to: the way we teach C is really, really bad.

Will you co-author my C book, that I'll write when I retire from coding? (that probably means in two decades or more 😝)

Show threadwitch_t *navi1d ago
@ska @dalias

i'll 100% co-author that book
Show threadVictor Mignot1d ago
@navi @dalias @ska I'll 100% read it
Show thread(1) Enno T. Boland1d ago
@vmignot @navi @dalias @ska I'll definitely acknowledge its existence and pretend I did read it!