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]

Message-ID: <CA+55aFxOrV5VwSt_O1-uvQQ=n2UrO0Gvb8wvvoLMk1fo1mvtng@mail.gmail.com>
Date:   Mon, 29 May 2017 20:20:14 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Keno Fischer <keno@...iacomputing.com>
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 ;)

On Mon, May 29, 2017 at 4:08 PM, Keno Fischer <keno@...iacomputing.com> wrote:
>
> 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.

Oh, we'll just re-instate the kernel behavior, it was more an
optimistic "maybe nobody will notice" thing, and apparently people did
notice.

What I *would* appreciate would be that with the revert, we'd describe
the apps that use FOLL_FORCE, and what they do.

Also, if we can limit it to some simpler cases, that would be good. For example:

 (a) if the "punch through" behavior is only used to punch through
read-only mappings, that one thing. It's FOLL_FORCE + FOLL_WRITE that
used to be a nasty case.

     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.

 (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".

So no, you should not need any workarounds, but it really would be
good to document what the uses are, and if you are ok with something
like the above that minimizes FOLL_FORCE usage, that would be good.

Mind sending me a patch with a comment or changelog like that?

                      Linus