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] [day] [month] [year] [list]

Message-ID: <CABgu+=P+y9QCwcT-+KncoAk6XvHbgaWBWwU3L7cy8qf9_M7ZVg@mail.gmail.com>
Date:	Wed, 10 Sep 2014 10:40:50 -0700
From:	Richard Larocque <rlarocque@...gle.com>
To:	John Stultz <john.stultz@...aro.org>
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 8:33 PM, John Stultz <john.stultz@...aro.org> wrote:
> 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

Sure, use the testing code as you see fit.  Let me know if you'd like
some boilerplate legalese statements to go along with it.
--
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/