David A. Wheeler wrote in <83f0cf09-6257-4949-9332-e6990cfe1...@dwheeler.com>: |Yves-Alexis Perez wrote in |> <6771f9536d49185fc8f1ea9905c13cf4dd8776d2.ca...@debian.org>: |> ... |>|mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7df\ |>|3000 | |On Jul 10, 2024, at 5:44 PM, Steffen Nurpmeso <stef...@sdaoden.eu> wrote: |> I thought on Linux MAP_DENYWRITE is actually an ignored flag. | |I believe you're correct, but I believe what Yves-Alexis Perez is showing \ |is the |flags that are being *passed* to the kernel (whether or not they DO \ |anything). |Which is why there's a proposal to *make* MAP_DENYWRITE do something \ |in this case. | |My plea is that if this DOES start doing something, PLEASE document \ |that ASAP |(including a note that it USED to be ignored). I fear that this security \ |property |might, on some platforms, depend on a quiet undocumented change.
Well i mean, i do not know, i am a user space programmer. And then the mmap(2) manual says MAP_DENYWRITE This flag is ignored. (Long ago—Linux 2.0 and earlier—it sig‐ naled that attempts to write to the underlying file should fail with ETXTBSY. But this was a source of denial‐of‐service at‐ tacks.) which is nice (i think bitsavers.org does not have any info, and we all know shall a future exist, this "cultural" epoch will be a whiteout beside that). But .. if you log the kernel you see for example 6e16f5133501440699dcca3c5aba367cf6f9c227 from 2023-07-24 saying selftests/mm: fix thuge-gen test bugs ... thuge-gen was also calling mmap with SHM_HUGETLB flag (bit 11 set), which is actually MAP_DENYWRITE in mmap context. The man page says this flag is ignored in modern kernels. I'm pretty sure from the context that the author intended to pass the MAP_HUGETLB flag so I've fixed that up too. or 49624efa65ac9889f4e7c7b2452b2e6ce42ba37d from 2021-09-04 Pull MAP_DENYWRITE removal from David Hildenbrand: "Remove all in-tree usage of MAP_DENYWRITE from the kernel and remove VM_DENYWRITE. There are some (minor) user-visible changes: ... or 6128b3af2a5e42386aa7faf37609b57f39fb7d00 from 2021-04-23 mm: ignore MAP_DENYWRITE in ksys_mmap_pgoff() Let's also remove masking off MAP_DENYWRITE from ksys_mmap_pgoff(): the last in-tree occurrence of MAP_DENYWRITE is now in LEGACY_MAP_MASK, which accepts the flag e.g., for MAP_SHARED_VALIDATE; however, the flag is ignored throughout the kernel now. Add a comment to LEGACY_MAP_MASK stating that MAP_DENYWRITE is ignored. so that is not too far in the past, and, sorry, but i am not so deep in the kernel / memory system scene to get an immediate notion, yet i think the topic is interesting for any (user space) programmer of any programming language that supports mapping memory directly. So if someone says "this was a source of denial‐of‐service attacks" then i need to wrap my head, and it is not as if an in-between-the-lines reference to MAP_DENYWRITE ring any bells except that i think the flag has been removed. And then someone who seems to know uses it nonetheless in a small showcase program, likely trying to say even more in-between-the-lines. And thus i live on the edge in between the Red Hot ChilliPeppers "if you have to ask, you will never know", and the Sesame Street, which at least in Germany was "sometimes you simply have to ask to understand a matter". Granted that "i think this flag was removed" is not a question as such. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)