On Wed, Jul 13, 2022 at 10:15 AM Ansgar Lößer
<ansgar.loesser@xxxxxxxxxxxxxxx> wrote:
>
>
> Thank you for the explanation. Unfortunately I was not able to reproduce
> this. I do understand, that being able to write to memory without being
> able to read from it cannot be implemented because of hardware
> limitations on many architectures.
Oh, you are right, we actually catch that situation, and require
FMODE_READ for all mmap's.
For some reason I was entirely sure that this had come up and we
didn't, but I see do_mmap() clearly doing
fallthrough;
case MAP_PRIVATE:
if (!(file->f_mode & FMODE_READ))
return -EACCES;
where that "fallthrough" is for the non-MAP_PRIVATE cases, so it hits
shared mappings too.
I was sure we had hit this case and it caused problems to check for
it, but that test goes back to before the git days (and in fact to
before the BK days).
So clearly my "clear memory" was complete garbage.
And thinking about it, I suspect said "clear memory" goes back to me
having issues with the original alpha port, where the hardware *did*
technically support write-only mappings (_PAGE_FOR set - "Fault On
Read", but _PAGE_FOW not set).
So alpha was the first port I did (and a big influence for how the
portable VM model came about), and page protections could be done
"right" in theory from a memory management standpoint.
But even then you can't actually do it, because writable maps required
reading _anyway_ - because the common alpha sequence was to do byte
accesses as "read-modify-write" longword accesses.
So that's likely the source of my conviction that write-only mappings
always require read accesses, but I had it exactly the wrong way
around - it's not even hardware-specific, but general, and just means
that we actually refuse to mmap() files that have been opened
write-only.
That should teach me to actually go and look at the code (or test),
not go by "I have a distinct memory".
Linus
