linux-kernel - Re: [PATCH 0/3] alarmtimer: Fix some non-standard alarm timer behavior

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: <CALAqxLWped1Qsh=Ps7Vc2=ORpKGNhjvKc-hWoA0Wg5aAf7O8Xg@mail.gmail.com>
Date:	Tue, 9 Sep 2014 20:33:04 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Richard Larocque <rlarocque@...gle.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] alarmtimer: Fix some non-standard alarm timer behavior

On Tue, Sep 9, 2014 at 6:31 PM, Richard Larocque <rlarocque@...gle.com> wrote:
> I've been working on some changes to posix-timers.c in an attempt to better
> support CRIU.  Along the way, I've discovered some issues with the posix alarm
> timers that should be fixed independent of any other work.
>
> It seems that there was an older issue with the setting of relative timeouts
> with timer_settime().  That was addressed around 3.16 with
> 16927776ae757d0d132bdbfabbfe2c498342bd59 ("alarmtimer: Fix bug where relative
> alarm timers were treated as absolute").  That fixed the setting of times, but
> it doesn't fix the retrieval of times.
>
> According to the man pages (and POSIX), timer_gettime() is supposed to return
> the time left until the timeout, not the absolute time at which the timeout is
> expected to fire.  The non-ALARM clocks correctly show relative times, but
> CLOCK_BOOTTIME_ALARM and CLOCK_REALTIME_ALARM do not.
>
> A second issue with these timers is that they call posix_event_timer() without
> checking the value of it_sigev_notify.  This is a problem, because
> it_sigev_notify could be SIGEV_NONE, in which case the signal should not be
> delivered.  The non-alarm timers don't need to check it_sigev_notify in their
> timeout handling code path, because they never schedule timeouts for those
> kinds of timers in the first place.
>
> See below for a program that demonstrates these behaviors, and some sample output.
>
> The third patch in this stack is the odd one out.  I suspect that there's
> a locking issue in the alarm timer code, and this is my attempt to fix it.
> It's not quite related to the first two, but it does conflict with one of them,
> so I figured I should include it in this patch stack.

Oof. More paper bags for me to wear. Thanks so much for discovering
these and providing these fixes.

I'll review and queue these up for my own testing and then send them
on (the locking one I'll have to look closely at). Do you mind if I
add a variant of your demo code to my timekeeping test suite?

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/