linux-kernel - Re: [git pull] vfs.git regression fix Re: Regression related to ipc shmctl compat

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+55aFxYFsD1DBt3uTGnmGvdZHi0Sz8Qcyswv_1nc34rU0bkUg@mail.gmail.com>
Date:   Mon, 25 Sep 2017 19:07:01 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Kyle Huey <me@...ehuey.com>,
        open list <linux-kernel@...r.kernel.org>,
        "Robert O'Callahan" <robert@...llahan.org>
Subject: Re: [git pull] vfs.git regression fix Re: Regression related to ipc
 shmctl compat

On Mon, Sep 25, 2017 at 7:03 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I agree. It might be better to just remove the address space logic,
> because afaik it never worked for them.

.. and sadly, we should probably disable the locking ones by default
too, because while they *work*, sparse only handles static cases, and
we have way too many dynamically conditional cases that are outside
the scope of what sparse does.

It would probably be good to disable things that are fundamentally
hard to fix, and aim for a clean sparse build, and maybe people would
start using it at least for user pointer checking where it really does
work.

Of course, even there it depends on pointers _statically_ being user
pointers, but happily we do largely follow that rule. We've had a few
nasty cases where we have a pointer that is conditionally user or
kernel pointer, but they are thankfully pretty rare.

                   Linus