linux-kernel - Re: [PATCH] signal: restore the override

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: <ZyZSotlacLgzWxUl@example.org>
Date: Sat, 2 Nov 2024 17:26:10 +0100
From: Alexey Gladkov <legion@...nel.org>
To: Andrei Vagin <avagin@...gle.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
	Roman Gushchin <roman.gushchin@...ux.dev>, oleg@...hat.com,
	linux-kernel@...r.kernel.org, Kees Cook <kees@...nel.org>,
	stable@...r.kernel.org
Subject: Re: [PATCH] signal: restore the override_rlimit logic

On Fri, Nov 01, 2024 at 03:44:48PM -0700, Andrei Vagin wrote:
> On Fri, Nov 1, 2024 at 1:58 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
> 
> > > Well, personally I'd not use this limit too, but I don't think
> > > "it's broken, userspace shouldn't use it" argument is valid.
> >
> > I said if you don't want the limit don't use it.
> >
> > A version of "Doctor it hurts when I do this". To which the doctor
> > replies "Don't do that then".
> 
> Unfortunately, it isn't an option here. This is a non-root user that
> creates a new user-namespace. It can't change RLIMIT_SIGPENDING
> beyond the current limit.
> 
> We have to distinguish between two types of signals:
> 
> * Kernel signals: These are essential for proper application behavior.
> If a user process triggers a memory fault, it gets SIGSEGV and it can’t
> ignore it. The number of such signals is limited by one per user thread.
> 
> * User signals: These are sent by users and can be blocked by the
> receiving process, potentially leading to a large queue of pending
> signals. This is where the RLIMIT_SIGPENDING limit plays its role in
> preventing excessive resource consumption.
> 
> New user namespaces inherit the current sigpending rlimit, so it is
> expected that  the behavior of the user-namespace limit is aligned with
> the overall RLIMIT_SIGPENDING mechanism.

Hm. I think I understand the problem now.

+Cc Oleg Nesterov.

-- 
Rgrds, legion