Marc Espie <es...@nerim.net> wrote: > On Wed, Oct 05, 2022 at 07:54:41AM -0600, Theo de Raadt wrote: > > Marc Espie <es...@nerim.net> wrote: > > > > > On Tue, Oct 04, 2022 at 10:15:51AM -0600, Theo de Raadt wrote: > > > > A note on why this chance is coming. > > > > > > > > malloc.c (as it is today), does mprotects back and forth between RW and > > > > R, to protect an internal object. This object is in bss, it is not > > > > allocated with mmap. With the upcoming mimmutable change, the bss will > > > > become immutable by default, at program load time. mimmutable even > > > > prevents > > > > changing a RW object to R. > > > > > > I'm probably missing something here, but for me, traditionally, > > > BSS is the "set to 0" section of global variables of a program... which > > > are > > > usually going to be changed to some other value. > > > > > > Or are we talking at cross purposes ? > > > > If you read the mimmutable diff, it has a manual page, and the answer is in > > there. > > Ah my mistake, I read a bit fast, and I thought the *pages* themselves were > immutable. > > Stupid question time: is there any reason not to allow further changes that > would *restrict* the pages further ? > > A bit like pledge works. > > Like, say you mark a region "immutable" with RW rights, then later on > use mprotect to mark it down RO, and you can never get back ?
I considered this when I first ran into the malloc and relpro issues, but after consideration I found no use for such a semantic. 1. that is even more difficult to explain 2. if permissions are reduced, it can still result in a program flow control behaviour via a signal handler 3. mimmutable's job is to change mmap/munmap/mprotect to return -1, it does not terminate programs 4. Many programs don't check for mprotect failure, so the addition of mimmutable already going to be interesting enough without adding demotion to the picture
