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]

Date:   Tue, 21 Jul 2020 13:06:41 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Gabriel Krisman Bertazi <krisman@...labora.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        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>,
        will@...nel.org, catalin.marinas@....com
Subject: Re: [PATCH v4 1/2] kernel: Implement selective syscall userspace
 redirection

On Thu, Jul 16, 2020 at 09:48:50PM -0700, Andy Lutomirski wrote:
> On Thu, Jul 16, 2020 at 7:15 PM Gabriel Krisman Bertazi
> <krisman@...labora.com> wrote:
> >
> > Andy Lutomirski <luto@...nel.org> writes:
> >
> > > On Thu, Jul 16, 2020 at 12:31 PM Gabriel Krisman Bertazi
> > > <krisman@...labora.com> wrote:
> > >>
> > >
> > > This is quite nice.  I have a few comments, though:
> > >
> > > You mentioned rt_sigreturn().  Should this automatically exempt the
> > > kernel-provided signal restorer on architectures (e.g. x86_32) that
> > > provide one?
> >
> > That seems reasonable.  Not sure how easy it is to do it, though.
> 
> For better or for worse, it's currently straightforward because the code is:
> 
> __kernel_sigreturn:
> .LSTART_sigreturn:
>         popl %eax               /* XXX does this mean it needs unwind info? */
>         movl $__NR_sigreturn, %eax
>         SYSCALL_ENTER_KERNEL
> 
> and SYSCALL_ENTER_KERNEL is hardwired as int $0x80.  (The latter is
> probably my fault, for better or for worse.)  So this would change to:
> 
> __vdso32_sigreturn_syscall:
>   SYSCALL_ENTER_KERNEL
> 
> and vdso2c would wire up __vdso32_sigreturn_syscall.  Then there would
> be something like:
> 
> bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs);
> 
> and that would be that.  Does anyone have an opinion as to whether
> this is a good idea?  Modern glibc shouldn't be using this mechanism,
> I think, but I won't swear to it.

On arm64 sigreturn is always through the vdso, so IIUC we'd certainly
need something like this. Otherwise it'd be the user's responsibility to
register the vdso sigtramp range when making the prctl, and flip the
selector in each signal handler, which sounds both painful and fragile.

Mark.