linux-kernel - 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-next>] [day] [month] [year] [list]

Date:   Mon, 29 May 2017 19:08:30 -0400
From:   Keno Fischer <keno@...iacomputing.com>
To:     linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        Kees Cook <keescook@...omium.org>, luto@...capital.net,
        ebiederm@...ssion.com, "Robert O'Callahan" <robert@...llahan.org>
Subject: Yes, people use FOLL_FORCE ;)

Hi Linus et al.,

In 8ee74a91 "proc: try to remove use of FOLL_FORCE entirely", you removed
punch through semantics of /proc/<pid>/mem. 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).

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). Also, judging by who complained last time FOLL_FORCE
was broken, I suspect the Wine people are relying on this as well.
Frankly, I'm a bit surprised that this change was made in the first place.
Making a userspace-breaking change on mainline and seeing if anybody
complains doesn't seem like the ideal way to find out if features are used.

As I said, personally we can patch our software and deal with this, but I think
a change like this deserves a bit wider discussion, so may I suggest a revert
of this change for the time being? Maybe there can be a syslog warning such
that people who use it will notice and have their say on the mailing list.

Thanks,
Keno