[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJqW0KK4QkMArH8Rmbax7EDfy1jE_8MSQ5VsUjAWgoU9g@mail.gmail.com>
Date: Mon, 27 Jul 2015 11:45:15 -0700
From: Kees Cook <keescook@...omium.org>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: "linuxppc-dev@...abs.org" <linuxppc-dev@...abs.org>,
LKML <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Will Drewry <wad@...omium.org>, strosake@...ux.vnet.ibm.com,
bogdan.purcareata@...escale.com
Subject: Re: [PATCH 01/11] powerpc/kernel: Switch to using MAX_ERRNO
On Thu, Jul 23, 2015 at 3:21 AM, Michael Ellerman <mpe@...erman.id.au> wrote:
> Currently on powerpc we have our own #define for the highest (negative)
> errno value, called _LAST_ERRNO. This is defined to be 516, for reasons
> which are not clear.
>
> The generic code, and x86, use MAX_ERRNO, which is defined to be 4095.
>
> In particular seccomp uses MAX_ERRNO to restrict the value that a
> seccomp filter can return.
>
> Currently with the mismatch between _LAST_ERRNO and MAX_ERRNO, a seccomp
> tracer wanting to return 600, expecting it to be seen as an error, would
> instead find on powerpc that userspace sees a successful syscall with a
> return value of 600.
>
> To avoid this inconsistency, switch powerpc to use MAX_ERRNO.
>
> We are somewhat confident that generic syscalls that can return a
> non-error value above negative MAX_ERRNO have already been updated to
> use force_successful_syscall_return().
>
> I have also checked all the powerpc specific syscalls, and believe that
> none of them expect to return a non-error value between -MAX_ERRNO and
> -516. So this change should be safe ...
>
> Acked-by: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> Signed-off-by: Michael Ellerman <mpe@...erman.id.au>
Reviewed-by: Kees Cook <keescook@...omium.org>
-Kees
> ---
> arch/powerpc/include/uapi/asm/errno.h | 2 --
> arch/powerpc/kernel/entry_32.S | 3 ++-
> arch/powerpc/kernel/entry_64.S | 5 +++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/uapi/asm/errno.h b/arch/powerpc/include/uapi/asm/errno.h
> index 8c145fd17d86..e8b6b5f7de7c 100644
> --- a/arch/powerpc/include/uapi/asm/errno.h
> +++ b/arch/powerpc/include/uapi/asm/errno.h
> @@ -6,6 +6,4 @@
> #undef EDEADLOCK
> #define EDEADLOCK 58 /* File locking deadlock error */
>
> -#define _LAST_ERRNO 516
> -
> #endif /* _ASM_POWERPC_ERRNO_H */
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 46fc0f4d8982..67ecdf61f4e3 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -20,6 +20,7 @@
> */
>
> #include <linux/errno.h>
> +#include <linux/err.h>
> #include <linux/sys.h>
> #include <linux/threads.h>
> #include <asm/reg.h>
> @@ -354,7 +355,7 @@ ret_from_syscall:
> SYNC
> MTMSRD(r10)
> lwz r9,TI_FLAGS(r12)
> - li r8,-_LAST_ERRNO
> + li r8,-MAX_ERRNO
> andi. r0,r9,(_TIF_SYSCALL_DOTRACE|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
> bne- syscall_exit_work
> cmplw 0,r3,r8
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 579e0f9a2d57..ee15d3c62e26 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -19,6 +19,7 @@
> */
>
> #include <linux/errno.h>
> +#include <linux/err.h>
> #include <asm/unistd.h>
> #include <asm/processor.h>
> #include <asm/page.h>
> @@ -207,7 +208,7 @@ system_call: /* label this so stack traces look sane */
> #endif /* CONFIG_PPC_BOOK3E */
>
> ld r9,TI_FLAGS(r12)
> - li r11,-_LAST_ERRNO
> + li r11,-MAX_ERRNO
> andi. r0,r9,(_TIF_SYSCALL_DOTRACE|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
> bne- syscall_exit_work
> cmpld r3,r11
> @@ -277,7 +278,7 @@ syscall_exit_work:
> beq+ 0f
> REST_NVGPRS(r1)
> b 2f
> -0: cmpld r3,r11 /* r10 is -LAST_ERRNO */
> +0: cmpld r3,r11 /* r11 is -MAX_ERRNO */
> blt+ 1f
> andi. r0,r9,_TIF_NOERROR
> bne- 1f
> --
> 2.1.0
>
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists