linux-kernel - Re: [PATCH 0/8] Isolate time_t data types for clock/timer syscalls

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:   Mon, 19 Jun 2017 12:31:00 -0700
From:   Deepa Dinamani <deepa.kernel@...il.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        John Stultz <john.stultz@...aro.org>,
        Nicolas Pitre <nicolas.pitre@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 0/8] Isolate time_t data types for clock/timer syscalls

> Check the stuff already in tip/timers/core; at the very least it overlaps
> considerably with your series.  And your variant is a lot more convoluted -
> there's no need to have a separate compat restart, etc.

Thanks, I see there were updates last week to the tree.

For the nanosleep part, I see that you guys addressed the problem differently.

These were my thoughts when I did the patch.

1. I wanted to maintain a strict layering approach i.e., I wanted all
the syscall and restart syscalls to be handled from k_clock layer.
   This means instead of each timer having to fill in its own restart
function, isn't it better for the behaviour to be mandated at posix
timers layer?
   Also, this way we can keep track of all the return values from the
internal layers and process them all the same way.

2. The new type argument to the restart_block for timespec will be
superfluous  after year 2038 as compat_timespec is not longer relevant
then.
    We can actually do away with it at that time. And, in the
meanwhile, there will be 2 compat versions for 64 bit time_t which
will be same as native format and the 32 bit format.
    Although this can handled because the 64 bit time_t compat and
native syscalls have same entry, it seems like we are adding a field
for just backward compatibility, just like the compat_timespec that is
already in the struct.

3. I was also aiming for user pointers to be not touched by timer
specific code as it can get messy if not handled properly with 2
compat time_t versions.

Do you guys see any benefit in doing it the way patch 4/8 in the
current series does?

-Deepa