All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dmitry Vyukov <dvyukov@google.com>,
	krisman@collabora.com, luto@kernel.org, peterz@infradead.org,
	keescook@chromium.org, gregory.price@memverge.com
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Marco Elver <elver@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] syscall_user_dispatch: Allow allowed range wrap-around
Date: Sat, 08 Mar 2025 12:19:17 +0100	[thread overview]
Message-ID: <87y0xf3h3e.ffs@tglx> (raw)
In-Reply-To: <de940218d0a59fd930ec244d87f2375b16a7815a.1740386567.git.dvyukov@google.com>

On Mon, Feb 24 2025 at 09:45, Dmitry Vyukov wrote:
> There are two possible scenarios for syscall filtering:
>  - having a trusted/allowed range of PCs, and intercepting everything else
>  - or the opposite: a single untrusted/intercepted range and allowing
>    everything else
> The current implementation only allows the former use case due to
> allowed range wrap-around check. Allow the latter use case as well
> by removing the wrap-around check.
> The latter use case is relevant for any kind of sandboxing scenario,
> or monitoring behavior of a single library. If a program wants to
> intercept syscalls for PC range [START, END) then it needs to call:
> prctl(..., END, -(END-START), ...);
> which sets a wrap-around range that excludes everything
> besides [START, END).

That's not really intuitive and the implementation changes the prctl()
behaviour in a non backwards compatible way.

Can we please keep the current behaviour and have a new mode. Something
like:

 # define PR_SYS_DISPATCH_OFF            0
 # define PR_SYS_DISPATCH_ON             1
 # define PR_SYS_DISPATCH_EXCLUSIVE_ON   PR_SYS_DISPATCH_ON
 # define PR_SYS_DISPATCH_INCLUSIVE_ON   2

That keeps the current mode backwards compatible and avoids the oddity of

     prctl(..., END, -(END-START), ...);

i.e. this is clearly and obvious distinguishable for user space:

     prctl(..., PR_SYS_DISPATCH_EXCLUSIVE_ON, END, END - START, ...);
     prctl(..., PR_SYS_DISPATCH_INCLUSIVE_ON, END, END - START, ...);

Which makes a lot of sense because these two modes are distinctly
different, no?

PR_SYS_DISPATCH_INCLUSIVE_ON will fail on older kernels and both modes
have a sanity check. PR_SYS_DISPATCH_INCLUSIVE_ON should at least check
for a zero length dispatcher region.

Aside of the better user interface this avoids the in_compat_syscall()
hack. Because then set_syscall_user_dispatch() does the range inversion
and that works completely independent of compat.

> kernel/entry/syscall_user_dispatch.c | 9 +++------
> kernel/sys.c                         | 6 ++++++
> 2 files changed, 9 insertions(+), 6 deletions(-)

This clearly lacks an update of

     Documentation/admin-guide/syscall-user-dispatch.rst

Thanks,

        tglx

  parent reply	other threads:[~2025-03-08 11:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1740386567.git.dvyukov@google.com>
2025-02-24  8:45 ` [PATCH v2 1/3] syscall_user_dispatch: Allow allowed range wrap-around Dmitry Vyukov
2025-03-08 10:00   ` Dmitry Vyukov
2025-03-08 11:19   ` Thomas Gleixner [this message]
2025-05-21 15:05     ` Dmitry Vyukov
2025-02-24  8:45 ` [PATCH v2 2/3] selftests: Fix errno checking in syscall_user_dispatch test Dmitry Vyukov
2025-03-03 16:06   ` Gregory Price
2025-03-08  9:57     ` Dmitry Vyukov
2025-03-08 12:34   ` Thomas Gleixner
2025-05-21 10:07     ` Dmitry Vyukov
2025-05-21 11:10       ` Thomas Weißschuh
2025-05-21 13:00         ` Dmitry Vyukov
2025-02-24  8:45 ` [PATCH v2 3/3] selftests: Extend syscall_user_dispatch test to check allowed range Dmitry Vyukov

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=87y0xf3h3e.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=gregory.price@memverge.com \
    --cc=keescook@chromium.org \
    --cc=krisman@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.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.