• L
    "Yes, people use FOLL_FORCE ;)" · f511c0b1
    Linus Torvalds 提交于
    This effectively reverts commit 8ee74a91 ("proc: try to remove use
    of FOLL_FORCE entirely")
    
    It turns out that people do depend on FOLL_FORCE for the /proc/<pid>/mem
    case, and we're talking not just debuggers. Talking to the affected people, the use-cases are:
    
    Keno Fischer:
     "We used these semantics as a hardening mechanism in the julia JIT. By
      opening /proc/self/mem and using these semantics, we could avoid
      needing RWX pages, or a dual mapping approach. We do have fallbacks to
      these other methods (though getting EIO here actually causes an assert
      in released versions - we'll updated that to make sure to take the
      fall back in that case).
    
      Nevertheless the /proc/self/mem approach was our favored approach
      because it a) Required an attacker to be able to execute syscalls
      which is a taller order than getting memory write and b) didn't double
      the virtual address space requirements (as a dual mapping approach
      would).
    
      I think in general this feature is very useful for anybody who needs
      to precisely control the execution of some other process. Various
      debuggers (gdb/lldb/rr) certainly fall into that category, but there's
      another class of such processes (wine, various emulators) which may
      want to do that kind of thing.
    
      Now, I suspect most of these will have the other process under ptrace
      control, so maybe allowing (same_mm || ptraced) would be ok, but at
      least for the sandbox/remote-jit use case, it would be perfectly
      reasonable to not have the jit server be a ptracer"
    
    Robert O'Callahan:
     "We write to readonly code and data mappings via /proc/.../mem in lots
      of different situations, particularly when we're adjusting program
      state during replay to match the recorded execution.
    
      Like Julia, we can add workarounds, but they could be expensive."
    
    so not only do people use FOLL_FORCE for both reads and writes, but they
    use it for both the local mm and remote mm.
    
    With these comments in mind, we likely also cannot add the "are we
    actively ptracing" check either, so this keeps the new code organization
    and does not do a real revert that would add back the original comment
    about "Maybe we should limit FOLL_FORCE to actual ptrace users?"
    Reported-by: NKeno Fischer <keno@juliacomputing.com>
    Reported-by: NRobert O'Callahan <robert@ocallahan.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    f511c0b1
base.c 84.0 KB