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

Message-ID: <Zmg0GoGnJFbPysfK@finisterre.sirena.org.uk>
Date: Tue, 11 Jun 2024 12:25:14 +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 Tue, Jun 11, 2024 at 01:26:50PM +0530, Dev Jain wrote:

> + * A signal is said to be delivered, when the program takes action on the
> + * signal: such action may involve termination of the process, ignoring the
> + * signal, terminating with core dump, stopping the process, or continuing the
> + * process if it was currently stopped. A signal is said to be blocked when the
> + * program refuses to take any of the above actions; note that, this is not the
> + * same as ignoring the signal. At a later time, the program may unblock the
> + * signal and then it will have to take one of the five actions
> + * described above.

I'm not sure that's what my understanding of a blocked signal is, I
would interpret "blocked" as a signal being masked (this usage can be
seen in for example sigaction(2)).  I'd also interpret delivery of the
signal as happening when the signal handler is invoked rather than
something that the handler has control over (the comment later on says
that so I think it's just an issue here).  Perhaps I'm confused about
terminology though, this is just usage I've picked up and ICBW.

> + * For standard signals (also see real-time signals in the man page), multiple
> + * blocked instances of the same signal are not queued; such a signal will
> + * be delivered just once.

See also SA_NODEFER.

> +	/* SEGV has been blocked in sa_mask, but ucontext is invariant */
> +	ret = sigismember(&(((ucontext_t *)uc)->uc_sigmask), SIGSEGV);
> +	ksft_test_result(ret == 0, "SEGV not blocked in ucontext\n");
> +
> +	/* USR1 has been blocked, but ucontext is invariant */
> +	ret = sigismember(&(((ucontext_t *)uc)->uc_sigmask), SIGUSR1);
> +	ksft_test_result(ret == 0, "USR1 not blocked in ucontext\n");

We're not manipulating the masks outside of main() so it's a bit unclear
what the mention of ucontext being invariant is all about here?

> +	/* Mangled ucontext implies USR2 is blocked for current thread */
> +	if (raise(SIGUSR2))
> +		ksft_exit_fail_perror("raise");
> +
> +	ksft_print_msg("USR2 bypassed successfully\n");
> +
> +	act.sa_sigaction = &handler_verify_ucontext;
> +	if (sigaction(SIGUSR1, &act, NULL))
> +		ksft_exit_fail_perror("Cannot install handler");
> +
> +	if (raise(SIGUSR1))
> +		ksft_exit_fail_perror("raise");
> +
> +	ksft_print_msg("USR2 still blocked on return from handler\n");

But we just raised SIGUSR1 rather than SIGUSR2?  If nothing else this
bit is a little unclear.

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