Significant raise of reports (on the Linux Kernel Mailing List) https://lwn.net/Articles/1065620/
-
@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.
@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
freewhen 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.
-
@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
freewhen 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.
@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 -
I don't think human reviewers are going to be able to keep up with the number of vulnerabilities we're seeing appear. I really don't. Humans won't be able to review at scale, and I also think that there's serious risks for blindly accepting AIgen patches, which for critical infrastructure could also be a path to *inserting new* vulnerabilities.
We need to attack this systemically.
I have more to say. More later. But that's the gist for now.
@cwebber It's a target rich environment.
I am also seeing cases where maintainers seem to be slamming "accept" on slop PRs and hoping for the best. Could be time pressure or burnout. -
@cwebber@social.coop we need microkernel based operating systems with capability-based security enforcement, isolation of components from each other as a baseline assumption, and formal verification of the whole thing at both the code and spec level, and we need all of this quite urgently
I'd set aside the formal verification requirement to get the rest of it. I really do think microkernels were the right way to go, it's just that in 1992 or whatever the consumer hardware wasn't up to the task. I think probably around 2005 or so the hardware started to be able to afford to do that. But that's approximately the time that VMs and containers took off. Now we have this giant mess.
-
I'd set aside the formal verification requirement to get the rest of it. I really do think microkernels were the right way to go, it's just that in 1992 or whatever the consumer hardware wasn't up to the task. I think probably around 2005 or so the hardware started to be able to afford to do that. But that's approximately the time that VMs and containers took off. Now we have this giant mess.
@dlakelan@mastodon.sdf.org @cwebber@social.coop i do not think that setting aside the formal verification is wise, and i also do not think it poses a technical barrier that we cannot surpass. especially since we already have formally verified microkernels with capability-based security that can be used today within full desktop operating systems
what needs to happen is for people to put the pieces together and polish it into a system regular folks can actually use -
I don't think human reviewers are going to be able to keep up with the number of vulnerabilities we're seeing appear. I really don't. Humans won't be able to review at scale, and I also think that there's serious risks for blindly accepting AIgen patches, which for critical infrastructure could also be a path to *inserting new* vulnerabilities.
We need to attack this systemically.
I have more to say. More later. But that's the gist for now.
@cwebber I like this summary so far. Youโre right to ALWAYS has to examine and test out results with every version. That is an odd feeling to remind yourself to question something you read, every time. I am sure young children wonโt have that feeling.
In fact, the whole concept of critical thinking is not necessarily taught in public schools any more in the US. This is the way it is if Republicans get into curriculum to ban this. Of course this goes along with banning diversity and inclusion.
I wonder if software has any sort of โcritical thinkingโ. It would only have the task of analyzing how many sources are producing a particular result and using that as a basis to repeat same.
-
@cwebber@social.coop we need microkernel based operating systems with capability-based security enforcement, isolation of components from each other as a baseline assumption, and formal verification of the whole thing at both the code and spec level, and we need all of this quite urgently
@linear @cwebber I think that might be what CHERI is trying to achieve: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
-
@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@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
) -
@dlakelan@mastodon.sdf.org @cwebber@social.coop i do not think that setting aside the formal verification is wise, and i also do not think it poses a technical barrier that we cannot surpass. especially since we already have formally verified microkernels with capability-based security that can be used today within full desktop operating systems
what needs to happen is for people to put the pieces together and polish it into a system regular folks can actually useIf you mean formally verifying the microkernel itself... yeah. I'm good with that. Isn't L4 formally verified? If you mean formally verifying every userspace daemon... Nice to have but I'm not holding my breath.
-
@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!)
@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..
-
@dlakelan@mastodon.sdf.org @cwebber@social.coop kernel is the bare minimum, i'd also want verification of at least specs around the hardware abstraction layer and how hardware related daemons talk to everything else. but it should definitely be possible for common system components and daemons as well, and i think should be mandatory for trusted daemons that supervise or manage other untrusted ones
i doubt everything will be formally verified, but it is nonetheless a goal that should be worked towards, while finding ways to develop standard practices and make it easier to apply everywhere -
@dlakelan@mastodon.sdf.org @cwebber@social.coop kernel is the bare minimum, i'd also want verification of at least specs around the hardware abstraction layer and how hardware related daemons talk to everything else. but it should definitely be possible for common system components and daemons as well, and i think should be mandatory for trusted daemons that supervise or manage other untrusted ones
i doubt everything will be formally verified, but it is nonetheless a goal that should be worked towards, while finding ways to develop standard practices and make it easier to apply everywhere@dlakelan@mastodon.sdf.org @cwebber@social.coop i'm glossing over a lot with the "trusted" vs "untrusted" here, and i recognize that. i've been thinking about this for the better part of a decade and conveying my mental model for this is not possible in a few pots in a social media thread
i just have not had the motivation or resources to spend on taking existing work in seL4/genode and assembling it with other pieces into the thing i'd like, writing specs, finding people to collaborate with on this, etc. life is busy and i already have so many projects -
@cwebber@social.coop we need microkernel based operating systems with capability-based security enforcement, isolation of components from each other as a baseline assumption, and formal verification of the whole thing at both the code and spec level, and we need all of this quite urgently
-
@dlakelan@mastodon.sdf.org @cwebber@social.coop kernel is the bare minimum, i'd also want verification of at least specs around the hardware abstraction layer and how hardware related daemons talk to everything else. but it should definitely be possible for common system components and daemons as well, and i think should be mandatory for trusted daemons that supervise or manage other untrusted ones
i doubt everything will be formally verified, but it is nonetheless a goal that should be worked towards, while finding ways to develop standard practices and make it easier to apply everywhereI agree it would be nice to have, but I honestly think it primarily prevents progress. We'd be wildly better off with microkernel OSes that are at the same level of hackiness as the Linux kernel, and maybe have decent interfaces that could get replaced piecemeal as people came up with alternative implementations in memory safe languages, and then maybe formally verified at a later date.
Right now, you have to be comfortable working in kernel space to even do anything
-
@BetaRays@p.changeme.fr.eu.org @cwebber@social.coop this would be part of my vision, yes
-
@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
) -
I agree it would be nice to have, but I honestly think it primarily prevents progress. We'd be wildly better off with microkernel OSes that are at the same level of hackiness as the Linux kernel, and maybe have decent interfaces that could get replaced piecemeal as people came up with alternative implementations in memory safe languages, and then maybe formally verified at a later date.
Right now, you have to be comfortable working in kernel space to even do anything
@dlakelan@mastodon.sdf.org @cwebber@social.coop right now, this minute, you can go download SculptOS and have a microkernel-based OS with capability security that can run on a laptop and use its iGPU and run a web browser and virtualize linux and build itself using the Genode framework it is based on. and you can use that framework to swap out the process-level-virtualization-based default microkernel (NOVA iirc) with the formally verified seL4 (or other L4 family kernels) and never have to care about the API/ABI differences between microkernels because it abstracts that for you, nor the code inside the kernel. -
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. ๐งต
@cwebber "- people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx""
I am not sure how this is going to work. How can be sure that the newest update is not a troyan horse (cf. recent axios breach)?
-
@dlakelan@mastodon.sdf.org @cwebber@social.coop right now, this minute, you can go download SculptOS and have a microkernel-based OS with capability security that can run on a laptop and use its iGPU and run a web browser and virtualize linux and build itself using the Genode framework it is based on. and you can use that framework to swap out the process-level-virtualization-based default microkernel (NOVA iirc) with the formally verified seL4 (or other L4 family kernels) and never have to care about the API/ABI differences between microkernels because it abstracts that for you, nor the code inside the kernel.
-
@dlakelan@mastodon.sdf.org @cwebber@social.coop right now, this minute, you can go download SculptOS and have a microkernel-based OS with capability security that can run on a laptop and use its iGPU and run a web browser and virtualize linux and build itself using the Genode framework it is based on. and you can use that framework to swap out the process-level-virtualization-based default microkernel (NOVA iirc) with the formally verified seL4 (or other L4 family kernels) and never have to care about the API/ABI differences between microkernels because it abstracts that for you, nor the code inside the kernel.@dlakelan@mastodon.sdf.org @cwebber@social.coop this is to say, what you are asking for exists, and has existed in a usable state for well over a decade, and is in some cases more feature complete than some other open source operating systems that people use and even daily drive
you can run it on a pinephone, too
