linux-kernel - Re: [patch v4 00/27] posix-timers: Cure the SIG

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: <87y13c293a.ffs@tglx>
Date: Fri, 27 Sep 2024 21:24:41 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Anna-Maria Behnsen
 <anna-maria@...utronix.de>, 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>, Oleg
 Nesterov <oleg@...hat.com>
Subject: Re: [patch v4 00/27] posix-timers: Cure the SIG_IGN mess

On Fri, Sep 27 2024 at 09:39, Eric W. Biederman wrote:
> I have stopped looking at this after patch 4.
>
> The current code can and does handle userspace injecting a signal with
> si_sys_private sent to an non-zero value using rt_sigqueueinfo(2) and
> that value will be delivered to userspace.
>
> I think the at least the ability to inject such a signal (ignoring
> si_sys_private) is very interesting for debuggers and checkpoint restart
> applications.
>
> I get the feeling the rest of the patch series depends upon not
> supporting userspace injecting signals with si_code == SI_TIMER.  That
> seems unnecessary.
>
> It seems reasonable to depend upon something like the SIGQUEUE_PREALLOC
> in the flags field of struct sigqueue to detect a kernel generated
> signal.  Rather than adding various hacks to make everything work
> with just a struct kernel_siginfo_t.  Especially as the timer signals
> today are the only signals that are preallocated.

Fair enough.

> Is there any chance 18/27 posix-timers: Embed sigqueue in struct k_itimer
> can be moved up?
>
> That should allow removing the reliance on si_sys_private.
>
> That should prevent the need to add another hack with sys_private_ptr in
> struct kernel_siginfo
>
> Perhaps what needs to happen is to update collect_signal to return the
> sigqueue entry (if it was preallocated), instead of the resched_timer.
> Then the timer code can just use container_of to get the struct
> k_itimer?
>
> After that si_sys_private can move into struct k_itimer, and the code
> won't need to worry about userspace setting that value, or about needing
> to clear that value.  As si_sys_private will always be 0 in preallocated
> signals.

Let me try that.

Thanks for taking a look!

       tglx