linux-kernel - Re: Yes, people use FOLL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 May 2017 14:54:25 -0400
From:   Keno Fischer <keno@...iacomputing.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...capital.net>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Robert O'Callahan" <robert@...llahan.org>
Subject: Re: Yes, people use FOLL_FORCE ;)

Hi Linus,

>      But it sounds like your JIT case actually uses it for writing -
> but if you can write a small blurb about it, that would be nice.

yes, we use it for writing. Happy to describe the scheme in more detail.

>  (b) it would probably be nice to limit FOLL_FORCE in general as much
> as possible, so if your case is about writing to your very _own_
> memory mapping, as opposed to writing to another process' memory,
> maybe we can do something like
>
>         if (mm == current->mm)
>                 flags |= FOLL_FORCE;
>
> which at least avoids the whole "let's change the VM in odd ways for a
> process that isn't even me".

While this would fix our current use case, we do have a use case for modifying
non-local address space as well (putting the JIT into a different
process). Similarly,
the rr use case precisely uses the remote mm case. 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.