From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: luto@kernel.org, tglx@linutronix.de, keescook@chromium.org,
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,
kernel@collabora.com
Subject: Re: [PATCH v8 3/7] kernel: Implement selective syscall userspace redirection
Date: Thu, 01 Jul 2021 13:09:21 -0400 [thread overview]
Message-ID: <87mtr6gdvi.fsf@collabora.com> (raw)
In-Reply-To: <8735szowmu.fsf@disp2133> (Eric W. Biederman's message of "Wed, 30 Jun 2021 16:44:41 -0500")
ebiederm@xmission.com (Eric W. Biederman) writes:
> Why does do_syscal_user_dispatch call do_exit(SIGSEGV) and
> do_exit(SIGSYS) instead of force_sig(SIGSEGV) and force_sig(SIGSYS)?
>
> Looking at the code these cases are not expected to happen, so I would
> be surprised if userspace depends on any particular behaviour on the
> failure path so I think we can change this.
Hi Eric,
There is not really a good reason, and the use case that originated the
feature doesn't rely on it.
Unless I'm missing yet another problem and others correct me, I think
it makes sense to change it as you described.
> Is using do_exit in this way something you copied from seccomp?
I'm not sure, its been a while, but I think it might be just that. The
first prototype of SUD was implemented as a seccomp mode.
> The reason I am asking is that by using do_exit you deprive userspace
> of the change to catch the signal handler and try and fix things.
>
> Also by using do_exit only a single thread of a multi-thread application
> is terminated which seems wrong.
>
> I am asking because I am going through the callers of do_exit so I can
> refactor things and clean things up and this use just looks wrong.
Thanks,
--
Gabriel Krisman Bertazi
next prev parent reply other threads:[~2021-07-01 17:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 19:32 [PATCH v8 0/7] Syscall User Dispatch Gabriel Krisman Bertazi
2020-11-27 19:32 ` [PATCH v8 1/7] x86: vdso: Expose sigreturn address on vdso to the kernel Gabriel Krisman Bertazi
2020-12-02 9:38 ` [tip: core/entry] " tip-bot2 for Gabriel Krisman Bertazi
2020-11-27 19:32 ` [PATCH v8 2/7] signal: Expose SYS_USER_DISPATCH si_code type Gabriel Krisman Bertazi
2020-12-02 9:38 ` [tip: core/entry] " tip-bot2 for Gabriel Krisman Bertazi
2020-11-27 19:32 ` [PATCH v8 3/7] kernel: Implement selective syscall userspace redirection Gabriel Krisman Bertazi
2020-12-01 22:57 ` Kees Cook
2020-12-02 9:38 ` [tip: core/entry] " tip-bot2 for Gabriel Krisman Bertazi
2020-12-02 14:12 ` tip-bot2 for Gabriel Krisman Bertazi
2021-06-30 21:44 ` [PATCH v8 3/7] " Eric W. Biederman
2021-07-01 17:09 ` Gabriel Krisman Bertazi [this message]
2020-11-27 19:32 ` [PATCH v8 4/7] entry: Support Syscall User Dispatch on common syscall entry Gabriel Krisman Bertazi
2020-12-01 22:57 ` Kees Cook
2020-12-02 0:04 ` Andy Lutomirski
2020-12-02 9:38 ` [tip: core/entry] " tip-bot2 for Gabriel Krisman Bertazi
2020-12-02 14:12 ` tip-bot2 for Gabriel Krisman Bertazi
2020-11-27 19:32 ` [PATCH v8 5/7] selftests: Add kselftest for syscall user dispatch Gabriel Krisman Bertazi
2020-12-02 9:38 ` [tip: core/entry] " tip-bot2 for Gabriel Krisman Bertazi
2020-12-02 14:12 ` tip-bot2 for Gabriel Krisman Bertazi
2020-11-27 19:32 ` [PATCH v8 6/7] selftests: Add benchmark " Gabriel Krisman Bertazi
2020-12-01 22:58 ` Kees Cook
2020-12-02 9:38 ` [tip: core/entry] " tip-bot2 for Gabriel Krisman Bertazi
2020-12-02 14:12 ` tip-bot2 for Gabriel Krisman Bertazi
2020-11-27 19:32 ` [PATCH v8 7/7] docs: Document Syscall User Dispatch Gabriel Krisman Bertazi
2020-12-01 22:21 ` Jonathan Corbet
2020-12-01 23:46 ` Thomas Gleixner
2020-12-01 22:53 ` Thomas Gleixner
2020-12-02 9:38 ` [tip: core/entry] " tip-bot2 for Gabriel Krisman Bertazi
2020-12-02 14:12 ` tip-bot2 for Gabriel Krisman Bertazi
2020-12-02 0:04 ` [PATCH v8 0/7] " Andy Lutomirski
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=87mtr6gdvi.fsf@collabora.com \
--to=krisman@collabora.com \
--cc=christian.brauner@ubuntu.com \
--cc=ebiederm@xmission.com \
--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.