Linus Torvalds torvalds@linux-foundation.org wrote:
Regarding mprotect(), POSIX also says:
An implementation may permit accesses other than those specified by prot; however, no implementation shall permit a write to succeed where PROT_WRITE has not been set or shall permit any access where PROT_NONE alone has been set.
When sealed memory is encountered in the middle of a range, an error will be returned (which almost noone looks at). Memory after the sealed region will not be fixed to follow this rule.
It may retain higher permission.
Maybe some atomicity rules have always been true for BSD, but they've never been true for Linux, and while I don't know how authoritative that opengroup thing is, it's what google found.
It is not a BSD thing. I searched many kernels. I did not find the Linux behaviour anywhere else.
(Linus, don't be a jerk)
I'm not the one who makes unsubstantiated statements and uses scare tactics to try to make said arguments sound more valid than they are.
So keep your arguments real, please.
CAN YOU PLEASE SHUT IT WITH THE PERSONAL ATTACKS? ARE YOU SO INSECURE THAT YOU NEED TO TAKE A TECHNICAL DISCUSSION AND MAKE IT PERSONAL?
In a new world of immutable / sealed memory, I believe there is a much bigger problem and I would appreciate if the Linux team would give it some consideration.
mprotect and munmap (and other calls) can now fail, due to intentional address space manipulation requested by a process (previously).
The other previous errors have been transient system effects, like ENOMEM.
This EPERM with partial change is not transient. A 5 line test program can show memory which is not released, or which memory will retain incorrect permissions.
Have any of you written test programs?