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: <20200510221510.GA948665@aurel32.net>
Date:   Mon, 11 May 2020 00:15:10 +0200
From:   Aurelien Jarno <aurelien@...el32.net>
To:     Christophe Leroy <christophe.leroy@...roup.eu>
Cc:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH fixes] powerpc/vdso32: Fallback on getres syscall when
 clock is unknown

Hi,

On 2020-05-09 09:42, Christophe Leroy wrote:
> There are other clocks than the standard ones, for instance
> per process clocks. Therefore, being above the last standard clock
> doesn't mean it is a bad clock. So, fallback to syscall instead
> of returning -EINVAL inconditionaly.
> 
> Fixes: e33ffc956b08 ("powerpc/vdso32: implement clock_getres entirely")
> Cc: stable@...r.kernel.org
> Reported-by: Aurelien Jarno <aurelien@...el32.net>
> Signed-off-by: Christophe Leroy <christophe.leroy@...roup.eu>
> ---
>  arch/powerpc/kernel/vdso32/gettimeofday.S | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S b/arch/powerpc/kernel/vdso32/gettimeofday.S
> index a3951567118a..e7f8f9f1b3f4 100644
> --- a/arch/powerpc/kernel/vdso32/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
> @@ -218,11 +218,11 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
>  	blr
>  
>  	/*
> -	 * invalid clock
> +	 * syscall fallback
>  	 */
>  99:
> -	li	r3, EINVAL
> -	crset	so
> +	li	r0,__NR_clock_getres
> +	sc
>  	blr
>    .cfi_endproc
>  V_FUNCTION_END(__kernel_clock_getres)

Thanks a lot for the fast answer. I have just tested this patch and I
confirm it fixes the issue.

Tested-by: Aurelien Jarno <aurelien@...el32.net>

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@...el32.net                 http://www.aurel32.net

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ