Re: [PATCH v8 7/7] docs: Document Syscall User Dispatch

From: Thomas Gleixner <tglx@linutronix.de>
To: Gabriel Krisman Bertazi <krisman@collabora.com>,
	luto@kernel.org, keescook@chromium.org
Cc: gofmanp@gmail.com, 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,
	Gabriel Krisman Bertazi <krisman@collabora.com>,
	kernel@collabora.com
Subject: Re: [PATCH v8 7/7] docs: Document Syscall User Dispatch
Date: Tue, 01 Dec 2020 23:53:06 +0100	[thread overview]
Message-ID: <87a6uxf8a5.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20201127193238.821364-8-krisman@collabora.com>

On Fri, Nov 27 2020 at 14:32, Gabriel Krisman Bertazi wrote:
> +Compatibility layers like Wine need a way to efficiently emulate system
> +calls of only a part of their process - the part that has the
> +incompatible code - while being able to execute native syscalls without
> +a high performance penalty on the native part of the process.  Seccomp
> +falls short on this task, since it has limited support to efficiently
> +filter syscalls based on memory regions, and it doesn't support removing
> +filters.  Therefore a new mechanism is necessary.
> +
> +Syscall User Dispatch brings the filtering of the syscall dispatcher
> +address back to userspace.  The application is in control of a flip
> +switch, indicating the current personality of the process.  A
> +multiple-personality application can then flip the switch without
> +invoking the kernel, when crossing the compatibility layer API
> +boundaries, to enable/disable the syscall redirection and execute
> +syscalls directly (disabled) or send them to be emulated in userspace
> +through a SIGSYS.
> +
> +The goal of this design is to provide very quick compatibility layer
> +boundary crosses, which is achieved by not executing a syscall to change
> +personality every time the compatibility layer executes.  Instead, a
> +userspace memory region exposed to the kernel indicates the current
> +personality, and the application simply modifies that variable to
> +configure the mechanism.
> +
> +There is a relatively high cost associated with handling signals on most
> +architectures, like x86, but at least for Wine, syscalls issued by
> +native Windows code are currently not known to be a performance problem,
> +since they are quite rare, at least for modern gaming applications.
> +
> +Since this mechanism is designed to capture syscalls issued by
> +non-native applications, it must function on syscalls whose invocation
> +ABI is completely unexpected to Linux.  Syscall User Dispatch, therefore
> +doesn't rely on any of the syscall ABI to make the filtering.  It uses
> +only the syscall dispatcher address and the userspace key.

I think this lacks information about the non-visiblity of these
syscalls. Something like this:

  As the ABI of these intercepted syscalls is unknown to Linux, these
  syscalls are not instrumentable via ptrace or the syscall tracepoints.

I'll add that unless someone objects or comes up with better wording
before I apply the lot tomorrow morning.

Thanks,

        tglx