Igor Stoppa posted a patch to allow kernel memory pools to be made read-only. Memory pools are a standard way to group memory allocations in Linux so their time cost is more predictable. With Igor's patch, once a memory pool was made read-only, it could not be made read-write again. This would secure the data for good and against attackers. Of course, you could free the memory and destroy the pool. But short of that, the data would stay read-only.

There was not much controversy about this patch. Kees Cook felt that XFS would work well with the feature. And, having an actual user would help Igor clarify the usage and nail down the API.

This apparently had come up at a recent conference, and Dave Chinner was ready for Igor's patch. He remarked, "we have a fair amount of static data in XFS that we set up at mount time and it never gets modified after that. I'm not so worried about VFS level objects (that's a much more complex issue) but there is a lot of low hanging fruit in the XFS structures we could convert to write-once structures."

Igor said this was exactly the kind of thing he'd had in mind.

A bunch of folks started talking about terminology and use cases, and speculating on further abilities. No one had any negative comment, and everyone was excited to get going with it.

The thing about a patch like this is that people can use the feature or not. It helps them with security, or it costs them nothing. It adds an ability but adds no complexity to the code. Unless something weird happens, I'd expect this patch to go into the kernel as soon as the API stabilizes.

Note: If you're mentioned above and want to post a response above the comment section, send a message with your response text to ljeditor@linuxjournal.com.