linux-kernel - Re: [PATCH v2 2/2] selftests: Add a test mangling with uc

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: <Zmq5uK0RfvgVKFdO@finisterre.sirena.org.uk>
Date: Thu, 13 Jun 2024 10:19:52 +0100
From: Mark Brown <broonie@...nel.org>
To: Dev Jain <dev.jain@....com>
Cc: shuah@...nel.org, oleg@...hat.com, stsp2@...dex.ru, mingo@...nel.org,
	tglx@...utronix.de, mark.rutland@....com, ryan.roberts@....com,
	suzuki.poulose@....com, Anshuman.Khandual@....com,
	DeepakKumar.Mishra@....com, AneeshKumar.KizhakeVeetil@....com,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] selftests: Add a test mangling with uc_sigmask

On Thu, Jun 13, 2024 at 10:21:39AM +0530, Dev Jain wrote:

> I guess we agree on the same thing; so, how about I rephrase the delivery
> and blocking code comments this way:
> "A process can request blocking of a signal by masking it into its set of
> blocked signals; such a signal, when sent to the process by the kernel, will
> get blocked by the process and it may later unblock it and take an action.
> At that point, the signal will be "delivered".

Yes.

> A signal sent by the kernel to the process, is said to be delivered to the
> process when the process takes an action upon receipt of the signal: such
> action may include termination, or jumping to a signal handler."

I'd just drop this last paragraph.

> > TBH I'm not sure what you mean there by real time signals, I can't see
> > a reference to real time in the copies of signal(2), signal(7) or
> > sigaction(2) on my system.  I suspect SA_NODEFER is the actual thing
> > here.

> Real-time signals get a mention on signal(7), under the heading
> "Real-time signals":

Ah, it's got a - in there so it doesn't show up in searches.

> > I still don't follow what the above means.  When you say "invariant" you
> > don't specify with respect to what, and it's not clear to me why the
> > saved context in ucontext would have changed without the handler writing
> > to it.  For clarity I think this needs to say what the ucontext is
> > expected to be the same as/different to.

> The ucontext at this stage is supposed to be empty, I guess I'll replace
> the word "invariant" then.
> "it's not clear to me why the saved context in ucontext would have changed
> without the handler writing to it" - by invariant I meant, the set of blocked
> signals before invocation of handler is exactly the set of signals blocked in
> ucontext, which, in this case, is the empty set. I'll just write that ucontext
> is empty.

Yes, or like I say in general it's the the interrupted context (there's
other parts of the signal frame which are changed).

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)