linux-kernel - Re: [patch V2 32/50] posix-timers: Make signal delivery consistent

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: <87bk67rmji.fsf@somnus>
Date: Thu, 18 Apr 2024 12:29:53 +0200
From: Anna-Maria Behnsen <anna-maria@...utronix.de>
To: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>
Cc: Frederic Weisbecker <frederic@...nel.org>, John Stultz
 <jstultz@...gle.com>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar
 <mingo@...nel.org>, Stephen Boyd <sboyd@...nel.org>, Eric Biederman
 <ebiederm@...ssion.com>, Oleg Nesterov <oleg@...hat.com>
Subject: Re: [patch V2 32/50] posix-timers: Make signal delivery consistent

Thomas Gleixner <tglx@...utronix.de> writes:

> Signals of timers which are reprogammed, disarmed or deleted can deliver
> signals related to the past. The POSIX spec is blury about this:
>
>  - "The effect of disarming or resetting a timer with pending expiration
>    notifications is unspecified."
>
>  - "The disposition of pending signals for the deleted timer is
>     unspecified."
>
> In both cases it is reasonable to expect that pending signals are
> discarded. Especially in the reprogramming case it does not make sense to
> account for previous overruns or to deliver a signal for a timer which has
> been disarmed. This makes the behaviour consistent and understandable.
>
> Remove the si_sys_private check from the signal delivery code and invoke
> posix_timer_deliver_signal() unconditionally.

s/posix_timer/posixtimer/ (or renaming the function when you introduced
it)

>
> Change that function so it controls the actual signal delivery via the
> return value. It now instructs the signal code to drop the signal when:
>
>   1) The timer does not longer exist in the hash table
>
>   2) The timer signal_seq value is not the same as the si_sys_private value
>      which was set when the signal was queued.
>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>

[...]

> --- a/kernel/time/posix-timers.c
> +++ b/kernel/time/posix-timers.c
> @@ -293,19 +297,19 @@ bool posixtimer_deliver_signal(struct ke
>  int posix_timer_queue_signal(struct k_itimer *timr)
>  {
>  	enum posix_timer_state state = POSIX_TIMER_DISARMED;
> -	int ret, si_private = 0;
>  	enum pid_type type;
> +	int ret;
>  
>  	lockdep_assert_held(&timr->it_lock);
>  
>  	if (timr->it_interval) {
> +		timr->it_signal_seq++;
>  		state = POSIX_TIMER_REQUEUE_PENDING;
> -		si_private = ++timr->it_signal_seq;
>  	}
>  	timr->it_status = state;
>  
>  	type = !(timr->it_sigev_notify & SIGEV_THREAD_ID) ? PIDTYPE_TGID : PIDTYPE_PID;
> -	ret = send_sigqueue(timr->sigq, timr->it_pid, type, si_private);
> +	ret = send_sigqueue(timr->sigq, timr->it_pid, type, timr->it_signal_seq);
>  	/* If we failed to send the signal the timer stops. */
>  	return ret > 0;
>  }

posix_timer_queue_signal() is executed, when a
posix/posix-cpu/alarmtimer expires. There is the check for it_interval
set, to decide whether reprogramming takes place or not.

If I understood it correctly, a resetted or deleted timer should not get
a signal delivered so it should also do not requeue a timer. But when
the timer expires at the same time when trying to reset or delete it,
the above it_interval check reduces the chance that a timer is
nevertheless requeued. Right?

> @@ -889,8 +891,6 @@ int common_timer_set(struct k_itimer *ti
>  	if (old_setting)
>  		common_timer_get(timr, old_setting);
>  
> -	/* Prevent rearming by clearing the interval */
> -	timr->it_interval = 0;

But here the clearing of the interval is removed. So it is more likely,
that the timer is reamed, when expiring and resetting happens at the
same time. Same thing when deleting the timer (see next hunk). Is this
ok, that the behavior changes like this?

But keeping the clearing of the interval is also a problem here - if I'm
not totally on the wrong track. When an expiry and resetting of the
timer happens together and old_setting is set, then the
timr->it_interval is cleared and timer_try_to_cancel() will fail so
TIMER_RETRY is returend to do_timer_settime(). In do_timer_settime() the
timr->it_interval is written into the old_setting struct. But this is
then cleared even if it was set before... hmm...

>  	/*
>  	 * Careful here. On SMP systems the timer expiry function could be
>  	 * active and spinning on timr->it_lock.
> @@ -1008,7 +1011,6 @@ int common_timer_del(struct k_itimer *ti
>  {
>  	const struct k_clock *kc = timer->kclock;
>  
> -	timer->it_interval = 0;
>  	if (kc->timer_try_to_cancel(timer) < 0)
>  		return TIMER_RETRY;
>  	timer->it_status = POSIX_TIMER_DISARMED;

Thanks,

	Anna-Maria