On Thu, Jul 23, 2015 at 3:21 AM, Michael Ellerman <m...@ellerman.id.au> wrote: > Currently the only caller of syscall_set_return_value() is seccomp > filter, which is not enabled on powerpc. > > This means we have not noticed that our implementation of > syscall_set_return_value() negates error, even though the value passed > in is already negative. > > So remove the negation in syscall_set_return_value(), and expect the > caller to do it like all other implementations do. > > Also add a comment about the ccr handling. > > Signed-off-by: Michael Ellerman <m...@ellerman.id.au>
Reviewed-by: Kees Cook <keesc...@chromium.org> -Kees > --- > arch/powerpc/include/asm/syscall.h | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/include/asm/syscall.h > b/arch/powerpc/include/asm/syscall.h > index c6239dabcfb1..cabe90133e69 100644 > --- a/arch/powerpc/include/asm/syscall.h > +++ b/arch/powerpc/include/asm/syscall.h > @@ -44,9 +44,15 @@ static inline void syscall_set_return_value(struct > task_struct *task, > struct pt_regs *regs, > int error, long val) > { > + /* > + * In the general case it's not obvious that we must deal with CCR > + * here, as the syscall exit path will also do that for us. However > + * there are some places, eg. the signal code, which check ccr to > + * decide if the value in r3 is actually an error. > + */ > if (error) { > regs->ccr |= 0x10000000L; > - regs->gpr[3] = -error; > + regs->gpr[3] = error; > } else { > regs->ccr &= ~0x10000000L; > regs->gpr[3] = val; > -- > 2.1.0 > -- Kees Cook Chrome OS Security _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev