linux-kernel - Re: MIPS: bug: gettimeofday syscall broken on CI20 board

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:   Wed, 27 Nov 2019 14:53:20 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Vincenzo Frascino <vincenzo.frascino@....com>
Cc:     Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paul.burton@...s.com>, linux-mips@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        MIPS Creator CI20 Development 
        <mips-creator-ci20-dev@...glegroups.com>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: MIPS: bug: gettimeofday syscall broken on CI20 board

Hi Vincenzo,

> Am 26.11.2019 um 11:52 schrieb Vincenzo Frascino <vincenzo.frascino@....com>:
> 
> Hi Nikolaus,
> 
> sorry for the delay in answering to your email but due to personal reasons I had
> to pull off the linux development for few weeks.

No problem.

> 
> On 17/11/2019 13:14, H. Nikolaus Schaller wrote:
>> Hi Vincenzo,
>> 
> 
> [...]
> 
>> 
>> If I look at the definition of vdso_data it *is* significantly differen
>> from mips_vdso_data.
>> 
>> What I would assume is that the struct mips_vdso_data is embossed in user
>> space code and therefore using vdso_data instead is breaking API.
>> 
> 
> vdso_data and mips_vdso_data before are not part of the ABI hence they are not
> bind by a contract with the userspace.
> 
> This means that they can change at any point and if a userspace software relies
> on a specific layout of these data structures is doing something wrong.

Maybe the libs are clever enough to find that out dynamically but I have no
idea about how gettimeofday() and user-space VDSO is implemented to handle such
changes.

> 
>> Please advise what I should try or check to narrow down further.
>> 
> 
> I had a look at [1] line 200 and seems that the error you are seeing is
> generated by:
>  if (gettimeofday(&tv, NULL) == -1) { ... }

Yes.

> I do not have a CI20 hence I can't do the test myself: could you please write a
> small application that invokes gettimeofday() as per above and report the
> behavior (I am even interested in the value returned). If we can reproduce the
> problem in a smaller environment it is easier to debug and get to the solution.
> 
> [1] http://users.isc.org/~each/doxygen/bind9/isc_2unix_2time_8c-source.html
> 
>> BR and thanks,
>> Nikolaus Schaller
>> 
> 
> Let me know.

I have done this and it seems as if tv_usec reports something that is beyond 1e6 us
or remains unchanged by the syscall. tv_sec seems to be set correctly. And,
gettimeofday() reports -1.

hwclock isn't set on 45.4 kernel because I have no ethernet connection due to the bug.

BR,
Nikolaus


Here is the log

a) with 5.4 kernel

root@...ux:~# cat gettime.c 
#include <stdio.h>
#include <time.h>
#include <sys/time.h>

int main(void)
{
struct timeval tv;
int r = gettimeofday(&tv, NULL);
time_t t;
int rt = time(&t);

printf("r = %d\n", r);
printf("tv.sec = %ld\n", tv.tv_sec);
printf("tv.usec = %d\n", tv.tv_usec);
printf("rt = %d\n", rt);
printf("t = %ld\n", t);
}
root@...ux:~# make gettime
cc     gettime.c   -o gettime
root@...ux:~# ./gettime 
r = -1
tv.sec = 1431857456
tv.usec = 2012065500
rt = 1478206565
t = 1478206565
root@...ux:~# ./gettime 
r = -1
tv.sec = 1431873840
tv.usec = 2012065500
rt = 1478206573
t = 1478206573
root@...ux:~# uname -a
Linux letux 5.4.0-letux-l400+ #1485 PREEMPT Wed Nov 27 10:23:16 CET 2019 mips GNU/Linux
root@...ux:~# cat /proc/cpuinfo 
system type             : JZ4780
machine                 : img,ci20
processor               : 0
cpu model               : Ingenic JZRISC V4.15  FPU V0.0
BogoMIPS                : 1196.85
wait instruction        : yes
microsecond timers      : no
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 1, address/irw mask: [0x0fff]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        :
shadow register sets    : 1
kscratch registers      : 0
package                 : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

root@...ux:~# dpkg -l | grep libc6
ii  libc6:mipsel                   2.24-11+deb9u4                 mipsel       GNU C Library: Shared libraries
ii  libc6-dev:mipsel               2.24-11+deb9u4                 mipsel       GNU C Library: Development Libraries and Header Files
root@...ux:~# cat /etc/debian_version 
9.11
root@...ux:~# 

b) same system booted with 4.19 kernel:

root@...ux:~# ./gettime 
r = 0
tv.sec = 1574862135
tv.usec = 27974
rt = 1574862135
t = 1574862135
root@...ux:~# uname -a
Linux letux 4.19.86-letux-l400+ #1450 PREEMPT Sun Nov 24 17:17:19 CET 2019 mips GNU/Linux
root@...ux:~# cat /proc/cpuinfo 
system type             : JZ4780
machine                 : img,ci20
processor               : 0
cpu model               : Ingenic JZRISC V4.15  FPU V0.0
BogoMIPS                : 1196.85
wait instruction        : yes
microsecond timers      : no
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 1, address/irw mask: [0x0fff]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        :
shadow register sets    : 1
kscratch registers      : 0
package                 : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

root@...ux:~# cat /etc/debian_version 
9.11
root@...ux:~#