musl - Re: Re: [RFC PATCH] x86/vdso/32: Add AT

Follow @Openwall on Twitter for new release announcements and other news

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

Message-ID: <20160310111646.GA13102@gmail.com>
Date: Thu, 10 Mar 2016 12:16:46 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Rich Felker <dalias@...c.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation
 helpers

* Rich Felker <dalias@...c.org> wrote:

> [...]
>
> I believe a new kernel cancellation API with a sticky cancellation flag (rather 
> than a signal), and a flag or'd onto the syscall number to make it cancellable 
> at the call point, could work, but then userspace needs to support fairly 
> different old and new kernel APIs in order to be able to run on old kernels 
> while also taking advantage of new ones, and it's not clear to me that it would 
> actually be worthwhile to do so. I could see doing it for a completely new 
> syscall API, but as a second syscall API for a system that already has one it 
> seems gratuitous. From my perspective the existing approach (checking program 
> counter from signal handler) is very clean and simple. After all it made enough 
> sense that I was able to convince the glibc folks to adopt it.

I concur with your overall analysis, but things get a bit messy once we consider 
AT_SYSINFO which is a non-atomic mix of user-space and kernel-space code. Trying 
to hand cancellation status through that results in extra complexity:

 arch/x86/entry/vdso/Makefile                      |   3 +-
 arch/x86/entry/vdso/vdso32/cancellation_helpers.c | 116 ++++++++++++++++++++++
 arch/x86/entry/vdso/vdso32/vdso32.lds.S           |   2 +
 tools/testing/selftests/x86/unwind_vdso.c         |  57 +++++++++--
 4 files changed, 171 insertions(+), 7 deletions(-)

So instead of a sticky cancellation flag, we could introduce a sticky cancellation 
signal.

A 'sticky signal' is not cleared from signal_pending() when the signal handler 
executes, but it's automatically blocked so no signal handler recursion occurs.
(A sticky signal could still be cleared via a separate mechanism, by the 
 cancellation cleanup code.)

Such a 'sticky cancellation signal' would, in the racy situation, cause new 
blocking system calls to immediately return with -EINTR. Non-blocking syscalls 
could still be used. (So the cancellation signal handler itself would still have 
access to various fundamental system calls.)

I think this would avoid messy coupling between the kernel's increasingly more 
varied system call entry code and C libraries.

Sticky signals could be requested via a new SA_ flag.

What do you think?

Thanks,

	Ingo

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.