linux-kernel - Re: [PATCH] FS: timerfd: Fix unexpected return value of timerfd

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 7 Sep 2019 16:38:55 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Arul Jeniston <arul.jeniston@...il.com>
cc:     viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, arul_mc@...l.com
Subject: Re: [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read
 function.

Arul,

On Fri, 6 Sep 2019, Arul Jeniston wrote:
> >Changing the return value to 1 would be just a cosmetic workaround.
> 
> Agreed. Returning 1 is incorrect as It causes the next read() to
> return before the interval time passed.
> 
> >So I rather change the documentation (this applies only to CLOCK_REALTIME
> >and CLOCK_REALTIME_ALARM) and explain the rationale.
> 
> When timerfd_read() returns 0, hrtimer_forward() doesn't change expiry
> time, So, instead of modifying the man page, can we call
> timerfd_read() functionality once again from kernel.
> 
> For example:-
> timerfd_read_wrapper()
> {
>    do {
>      ret = timerfd_read(...);
>    } while (ret == 0);
> }
> 
> Let us know whether you see any problem in handling this race in kernel.

There is no race. It's defined behaviour and I explained it to you in great
length why it is correct to return 0 and document that in the man page.

Any CLOCK_REALTIME ABSTIME based interface of the kernel is affected by
this and no, we are not papering over it in one particular place just
because.

If clock REALTIME gets set then all bets are off. The syscalls can return
either early or userspace cam observe that the return value is bogus when
it actually reads the time. You cannot handle this by any means.

The only way to handle this gracefully is by using the
TFD_TIMER_CANCEL_ON_SET flag and reevaluate the situation in user space.

So I'm going to send a patch to document that in the manpage.

Thanks,

	tglx