All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: luto@kernel.org, Rich Felker <dalias@libc.org>
Cc: tglx@linutronix.de, keescook@chromium.org,
	christian.brauner@ubuntu.com, peterz@infradead.org,
	willy@infradead.org, shuah@kernel.org,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	linux-kselftest@vger.kernel.org, x86@kernel.org,
	gofmanp@gmail.com, kernel@collabora.com
Subject: Re: [PATCH v7 3/7] kernel: Implement selective syscall userspace redirection
Date: Thu, 19 Nov 2020 12:43:05 -0500	[thread overview]
Message-ID: <87a6vdmedy.fsf@collabora.com> (raw)
In-Reply-To: <20201118032840.3429268-4-krisman@collabora.com> (Gabriel Krisman Bertazi's message of "Tue, 17 Nov 2020 22:28:36 -0500")

Gabriel Krisman Bertazi <krisman@collabora.com> writes:

> Introduce a mechanism to quickly disable/enable syscall handling for a
> specific process and redirect to userspace via SIGSYS.  This is useful
> for processes with parts that require syscall redirection and parts that
> don't, but who need to perform this boundary crossing really fast,
> without paying the cost of a system call to reconfigure syscall handling
> on each boundary transition.  This is particularly important for Windows
> games running over Wine.

I raised a discussion about this on libc-alpha, as requested by Florian.
At the moment, there was some back and forth on why the use-case is not
done by seccomp, but a more interesting point about user_notif was
raised by Rich Felker (cc'ed).

SIGSYS, as a signal handler, is limited in what can be done inside it.
Rich suggested the user_notif design is a better solution.  I understand
that from a Wine perspective, SIGSYS suffices for their work, but would
it make sense to extend SUD interface to support a user_notif-like
interface?  Would this be acceptable as future work to be added when/if
needed, or should we design it from the start?

The existing interface could be extended with a flags field as part of
the opcode passed in argument 2, which is currently reserved, and then
return a FD, just like seccomp(2) does.  So it is not like the current
patches couldn't be extended in the future if needed, unless I'm
mistaken.

-- 
Gabriel Krisman Bertazi

  parent reply	other threads:[~2020-11-19 17:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18  3:28 [PATCH v7 0/7] Syscall User Dispatch Gabriel Krisman Bertazi
2020-11-18  3:28 ` [PATCH v7 1/7] x86: vdso: Expose sigreturn address on vdso to the kernel Gabriel Krisman Bertazi
2020-11-18  3:28 ` [PATCH v7 2/7] signal: Expose SYS_USER_DISPATCH si_code type Gabriel Krisman Bertazi
2020-11-18  3:28 ` [PATCH v7 3/7] kernel: Implement selective syscall userspace redirection Gabriel Krisman Bertazi
2020-11-19 12:36   ` Peter Zijlstra
2020-11-19 17:43   ` Gabriel Krisman Bertazi [this message]
2020-11-21  0:18     ` Kees Cook
2020-11-22  4:01       ` Andy Lutomirski
2020-11-18  3:28 ` [PATCH v7 4/7] entry: Support Syscall User Dispatch on common syscall entry Gabriel Krisman Bertazi
2020-11-18  3:28 ` [PATCH v7 5/7] selftests: Add kselftest for syscall user dispatch Gabriel Krisman Bertazi
2020-11-18  3:28 ` [PATCH v7 6/7] selftests: Add benchmark " Gabriel Krisman Bertazi
2020-11-18  3:28 ` [PATCH v7 7/7] docs: Document Syscall User Dispatch Gabriel Krisman Bertazi
2020-11-18  8:48   ` Florian Weimer
2020-11-18 17:02     ` Gabriel Krisman Bertazi
2020-11-18  8:47 ` [PATCH v7 0/7] " Florian Weimer
2020-11-18 17:01   ` Gabriel Krisman Bertazi
2020-11-18 17:22     ` Florian Weimer
2020-11-19 12:38 ` Peter Zijlstra
2020-11-21  0:24   ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a6vdmedy.fsf@collabora.com \
    --to=krisman@collabora.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=dalias@libc.org \
    --cc=gofmanp@gmail.com \
    --cc=keescook@chromium.org \
    --cc=kernel@collabora.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.