On Tue, Dec 12, 2023 at 4:39 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 12 Dec 2023 at 15:17, <jeffxu@xxxxxxxxxxxx> wrote: > > + > > +**types**: bit mask to specify the sealing types, they are: > > I really want a real-life use-case for more than one bit of "don't modify". > For the real-life use case question, Stephen Röttger and I put description in the cover letter as well as the open discussion section (mseal() vs immutable()) of patch 0/11. Perhaps you are looking for more details in chrome usage of the API, e.g. code-wise ? > IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is ok"? > The MADV_DONTNEED is OK for file-backed mapping. As state in man page of madvise: [1] "subsequent accesses of pages in the range will succeed, but will result in either repopulating the memory contents from the up-to-date contents of the underlying mapped file" > Or when would you *ever* say "seal this area, but mprotect()" is ok. > The fact that openBSD allows RW=>RO transaction, as in its man page [2] " At present, mprotect(2) may reduce permissions on immutable pages marked PROT_READ | PROT_WRITE to the less permissive PROT_READ." suggests application might desire multiple ways to seal the "PROT" bits. E.g. Applications that wants a full lockdown of PROT and PKEY might use SEAL_PROT_PKEY (Chrome case and implemented in this patch) Application that desires RW=>RO transaction, might implement SEAL_PROT_DOWNGRADEABLE, or specifically allow RW=>RO. (not implemented but can be added in future as extension if needed.) > IOW, I want to know why we don't just do the BSD immutable thing, and > why we need this multi-level sealing thing. > The details are discussed in mseal() vs immutable()) of the cover letter (patch 0/11) In short, BSD's immutable is designed specific for libc case, and Chrome case is just different (e.g. the lifetime of those mappings and requirement of free/discard unused memory). Single bit vs multi-bits are still up for discussion. If there are strong opinions on the multiple-bits approach, (and no objection on applying MM_SEAL_DISCARD_RO_ANON to the .text part during libc dynamic loading, which has no effect anyway because it is file backed.), we could combine all three bits into one. A side note is that we could not add something such as SEAL_PROT_DOWNGRADEABLE later, since pkey_mprotect is sealed. I'm open to one bit approach. If we took that approach, We might consider the following: mseal() or mseal(flags), flags are reserved for future use. I appreciate a direction on this. [1] https://man7.org/linux/man-pages/man2/madvise.2.html [2] https://man.openbsd.org/mimmutable.2 -Jeff > Linus
