On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said: > On Fri, Oct 19, 2018 at 10:32 AM, <valdis.kletnieks@xxxxxx> 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"....
Attachment:
pgpR35n6fZupX.pgp
Description: PGP signature
