linux-kernel - Re: [PATCH v4 1/2] kernel: Implement selective syscall userspace redirection

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: <20200720094437.GA11405@willie-the-truck>
Date:   Mon, 20 Jul 2020 10:44:38 +0100
From:   Will Deacon <will@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Gabriel Krisman Bertazi <krisman@...labora.com>,
        LKML <linux-kernel@...r.kernel.org>, kernel@...labora.com,
        Matthew Wilcox <willy@...radead.org>,
        Paul Gofman <gofmanp@...il.com>,
        Kees Cook <keescook@...omium.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>, Shuah Khan <shuah@...nel.org>
Subject: Re: [PATCH v4 1/2] kernel: Implement selective syscall userspace
 redirection

On Mon, Jul 20, 2020 at 11:23:13AM +0200, Thomas Gleixner wrote:
> Andy Lutomirski <luto@...nel.org> writes:
> > On Thu, Jul 16, 2020 at 12:31 PM Gabriel Krisman Bertazi
> > <krisman@...labora.com> wrote:
> > The amount of syscall entry wiring that arches need to do is IMO
> > already a bit out of hand.  Should we instead rename TIF_SECCOMP to
> > TIF_SYSCALL_INTERCEPTION and have one generic callback that handles
> > seccomp and this new thing?
> 
> The right way to go is to consolidate all the stupidly different
> entry/exit work handling implementations and have exactly one in generic
> code, i.e. what I posted a few days ago.
> 
> Then we can make new features only available in the generic version by
> hiding the new functionality in the core code and not exposing the
> functions to architecture implementations.
> 
> Making it easy for architectures to keep their own variant forever just
> proliferates the mess we have right now.

Couldn't agree more. We recently added PTRACE_SYSEMU to arm64 and I deeply
regret doing that now that yet another way to rewrite the syscall number
has come along. I only just untangled some of the mess in our entry code
for that, so I can't say I'm looking forward to opening it right back up
to support this new feature. Much better to do it in the core code instead.

Will