linux-kernel - Re: [PATCH v4 0/2] make sigaltstack() compatible with swapcontext()

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56DC92AE.3070707@list.ru>
Date:	Sun, 6 Mar 2016 23:27:26 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Szabolcs Nagy <nsz@...t70.net>
Cc:	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>,
	Oleg Nesterov <oleg@...hat.com>,
	Shuah Khan <shuahkh@....samsung.com>
Subject: Re: [PATCH v4 0/2] make sigaltstack() compatible with swapcontext()

06.03.2016 23:02, Szabolcs Nagy пишет:
> * Stas Sergeev <stsp@...t.ru> [2016-03-01 00:29:03 +0300]:
>> The following patches make it possible to use swapcontext()
>> in a sighandler that works on sigaltstack.
> i don't think that's possible, the (obsolete) userspace
> *context functions cannot operate on kernel provided
> ucontext_t structs,
It doesn't have to.
It does the normal getcontext()/swapcontext() sequences,
as if it would be switching from any casual code place.
Kernel-provided context structs are completely irrelevant.
For more details please see the test-case I posted in that patch series.
It shows what can be done and how.

>   so they are not usable in signal
> handlers.
Please note the fact that swapcontext() also replaces the
signal mask as part of the context switching. This is a very
strong hint that it was intended to work with signal handlers.
And in fact it perfectly does.
What I want is only to make it friendly to sigaltstack.
I am not making it friendly to signal handlers in general,
because it already is.

> at least not on most target archs.
>
> so i don't understand how the tests can work portably.
If you apply my patch series, you can immediately test
it on any arch you want, thanks to the test-case my patch
adds to the kernel. Please let me know on what arch it fails.