Re: [RFC PATCH v3 2/3] seccomp: add kernel-installed pinned-memfd redirect

[Andy Lutomirski]

On Tue, Jun 23, 2026 at 12:11 PM Kees Cook <kees@xxxxxxxxxx> wrote:
>
> On Tue, Jun 23, 2026 at 12:02:32PM -0700, Andy Lutomirski wrote:
> > I'm really not convinced that the min is needed to preserve any useful
> > behavior.  But Kees is very conservative about these things, with good
> > reason.
>
> What is going to use this feature? I'd rather not try to have a USER_NOTIF
> security boundary since there are so many corner cases.

This whole redirect-to-pinned-memory mechanism for starters -- it's
extremely useful I think.

But maybe that particular usecase could be a lot narrower than I'm
making it out to be.  In this particular patch, the redirect is for a
single syscall.  We could say that the user cannot redirect to a
different syscall nr (mostly to make it easier to reason about the
code), and this patch already has the (rather limiting) property that
one can only redirect to a *single* syscall.  So the controller
process doesn't get full control over the target process.  And maybe
we just declare signal handling to be out of scope in the sense that
intelligent handling of syscalls that have complex signal handling
(e.g. nanosleep, although I don't really know why you would want to
redirect the pointer argument to nanosleep) are unlikely to be
handle-able correctly, and the user should avoid redirecting those
syscalls.

I don't think USER_NOTIF should become more of a security boundary
than it already is, although this redirect feature is very much
security-sensitive if it gets used.


The implementation of the patch is a bit sad -- there is no technical
reason that the code couldn't actually issue the syscall and avoid all
the heap and task-work crud.  The kernel isn't really structured like
that, but I don't think it would be a big departure.

--Andy