Google is proposing a new mseal() memory sealing system call for the Linux kernel. Google intends for this architecture independent system call to be initially used by the Google Chrome web browser on Chrome OS while experiments are underway for use by Glibc in the dynamic linker to seal all non-writable segments at startup.
The discussion is ongoing, so you can read the original proposed patchset and go from there.
Right! And the return value of this syscall should be – the amount of carbon emission
reduced due to not modifying the metadata of virtual addresses.
I kind of question the value of such things. But then again I guess that being able to trust your own code is too idealistic 🙁
“I’m going to ask you for something in the future and you should deny me”
I kind of feel that the operating system’s purpose is to protect processes from each other, which makes a lot of sense. But now we’re asking the OS to protect processes from themselves…is just seems like it’s going down a rabbit hole. Where do you draw the line with such logic? Ostensibly you could have a denial bitmap for lots of syscalls because code that doesn’t trust itself could do literally anything to it’s own process.
“If I fork/exec in the future, you should deny me”
“If I open a tcp socket, you should deny me”
“If I try to allocate more memory, you should deny me”
etc.
Reading the thread, especially the remarks from infamous Theo de Raadt, it seems like the “patch” is not cooked enough, and was tried to be merged prematurely.
The main problem being, it is not clean, and does not serve a purpose that was not done better elsewhere. Little gems like:
Or:
I would highly recommend reading them starting from:
https://lore.kernel.org/lkml/[email protected]/
(Not to pile on the engineer who did the work though. They built something, and thought that they had a solution, without realizing the scope of the problem, nor the alternatives).