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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAOp6jLZaMNQDrVxR9_yEa2Lh8_AgnuLQtk2yHF6zYRfVePYkHw@mail.gmail.com>
Date:   Tue, 30 May 2017 12:21:28 +1200
From:   "Robert O'Callahan" <robert@...llahan.org>
To:     unlisted-recipients:; (no To-header on input)
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Yes, people use FOLL_FORCE ;)

On Tue, May 30, 2017 at 11:08 AM, Keno Fischer <keno@...iacomputing.com> wrote:
> Now, while we're probably fine with using the fallbacks, I know there's
> others that rely on this behavior as well (cc'ing Robert O'Callahan of the
> rr project for which this change will result in significant performance
> degradation).

Yeah, this breaks rr. 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. For
small writes we can fall back to PTRACE_POKEDATA without much
performance loss, but for big writes it would be cheaper to
sock-puppet the ptracee to call mprotect to temporarily make pages
writeable. Of course that takes at least four context switches, so the
lower-bound overhead of that approach is pretty bad. OTOH there are
probably tricks we could pull to mitigate the overhead some more. For
example during replay we might be able to make some pages that
"should" be read-only actually be read-write when we know the recorded
process didn't try writing to them.

So in summary: rr can be upgraded to cope with this, incurring some
unknown amount of additional overhead, but existing rr installs will
definitely be totally broken.

Thanks,
Rob