On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said:
On Fri, Oct 19, 2018 at 10:32 AM, valdis.kletnieks@vt.edu wrote:
What is supposed to happen if some other process has an already existing R/W mmap of the region? (For that matter, the test program doesn't seem to actually test that the existing mmap region remains writable?)
Why would it not remain writable? We don't change anything in the mapping that prevents it from being writable, in the patch.
OK, if the meaning here is "if another process races and gets its own R/W mmap before we seal our mmap, it's OK". Seems like somewhat shaky security-wise - a possibly malicious process can fail to get a R/W map because we just sealed it, but if it had done the attempt a few milliseconds earlier it would have its own R/W mmap to do as it pleases...
On the other hand, decades of trying have proven that trying to do any sort of revoke() is a lot harder to do than it looks...
We do test that existing writable mmaps can continue to exist after the seal is set, in a way, because we test that setting of the seal succeeds.
Well, if the semantics are "We don't bother trying to deal with existing R/W maps", then it doesn't really matter - I was thinking along the lines of "If we're revoking other R/W accesses, we should test that we didn't nuke *this* one in the bargain"....