linux-toradex.git/kernel/rseq.c, branch v5.13-rc3

rseq: Optimise rseq_get_rseq_cs() and clear_rseq_cs()

2021-04-14T16:04:09+00:00

Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
update includes") added regressions for our servers.

Using copy_from_user() and clear_user() for 64bit values
is suboptimal.

We can use faster put_user() and get_user() on 64bit arches.

Signed-off-by: Eric Dumazet 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Mathieu Desnoyers 
Link: https://lkml.kernel.org/r/20210413203352.71350-4-eric.dumazet@gmail.com

rseq: Remove redundant access_ok()

2021-04-14T16:04:09+00:00

After commit 8f2817701492 ("rseq: Use get_user/put_user rather
than __get_user/__put_user") we no longer need
an access_ok() call from __rseq_handle_notify_resume()

Mathieu pointed out the same cleanup can be done
in rseq_syscall().

Signed-off-by: Eric Dumazet 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Mathieu Desnoyers 
Link: https://lkml.kernel.org/r/20210413203352.71350-3-eric.dumazet@gmail.com

rseq: Optimize rseq_update_cpu_id()

2021-04-14T16:04:09+00:00

Two put_user() in rseq_update_cpu_id() are replaced
by a pair of unsafe_put_user() with appropriate surroundings.

This removes one stac/clac pair on x86 in fast path.

Signed-off-by: Eric Dumazet 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Mathieu Desnoyers 
Link: https://lkml.kernel.org/r/20210413203352.71350-2-eric.dumazet@gmail.com

rseq: Reject unknown flags on rseq unregister

2019-12-25T09:41:20+00:00

It is preferrable to reject unknown flags within rseq unregistration
rather than to ignore them. It is an oversight caused by the fact that
the check for unknown flags is after the rseq unregister flag check.

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20191211161713.4490-2-mathieu.desnoyers@efficios.com
Signed-off-by: Ingo Molnar

signal: Remove task parameter from force_sig

2019-05-27T14:36:28+00:00

All of the remaining callers pass current into force_sig so
remove the task parameter to make this obvious and to make
misuse more difficult in the future.

This also makes it clear force_sig passes current into force_sig_info.

Signed-off-by: "Eric W. Biederman"

signal: Remove task parameter from force_sigsegv

2019-05-27T14:36:28+00:00

The function force_sigsegv is always called on the current task
so passing in current is redundant and not passing in current
makes this fact obvious.

This also makes it clear force_sigsegv always calls force_sig
on the current task.

Signed-off-by: "Eric W. Biederman"

rseq: Remove superfluous rseq_len from task_struct

2019-04-19T10:39:32+00:00

The rseq system call, when invoked with flags of "0" or
"RSEQ_FLAG_UNREGISTER" values, expects the rseq_len parameter to
be equal to sizeof(struct rseq), which is fixed-size and fixed-layout,
specified in uapi linux/rseq.h.

Expecting a fixed size for rseq_len is a design choice that ensures
multiple libraries and application defining __rseq_abi in the same
process agree on its exact size.

Considering that this size is and will always be the same value, there
is no point in saving this value within task_struct rseq_len. Remove
this field from task_struct.

No change in functionality intended.

Signed-off-by: Mathieu Desnoyers 
Acked-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Ben Maurer 
Cc: Boqun Feng 
Cc: Catalin Marinas 
Cc: Chris Lameter 
Cc: Dave Watson 
Cc: H. Peter Anvin 
Cc: Joel Fernandes 
Cc: Josh Triplett 
Cc: Linus Torvalds 
Cc: Michael Kerrisk 
Cc: Paul E. McKenney 
Cc: Paul Turner 
Cc: Peter Zijlstra 
Cc: Russell King 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: linux-api@vger.kernel.org
Link: http://lkml.kernel.org/r/20190305194755.2602-3-mathieu.desnoyers@efficios.com
Signed-off-by: Ingo Molnar

rseq: Clean up comments by reflecting removal of event counter

2019-04-19T10:39:31+00:00

The "event counter" was removed from rseq before it was merged upstream.
However, a few comments in the source code still refer to it. Adapt the
comments to match reality.

Signed-off-by: Mathieu Desnoyers 
Acked-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Ben Maurer 
Cc: Boqun Feng 
Cc: Catalin Marinas 
Cc: Chris Lameter 
Cc: Dave Watson 
Cc: H. Peter Anvin 
Cc: Joel Fernandes 
Cc: Josh Triplett 
Cc: Linus Torvalds 
Cc: Michael Kerrisk 
Cc: Paul E. McKenney 
Cc: Paul Turner 
Cc: Peter Zijlstra 
Cc: Russell King 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: linux-api@vger.kernel.org
Link: http://lkml.kernel.org/r/20190305194755.2602-2-mathieu.desnoyers@efficios.com
Signed-off-by: Ingo Molnar

Remove 'type' argument from access_ok() function

2019-01-04T02:57:57+00:00

Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
of the user address range verification function since we got rid of the
old racy i386-only code to walk page tables by hand.

It existed because the original 80386 would not honor the write protect
bit when in kernel mode, so you had to do COW by hand before doing any
user access.  But we haven't supported that in a long time, and these
days the 'type' argument is a purely historical artifact.

A discussion about extending 'user_access_begin()' to do the range
checking resulted this patch, because there is no way we're going to
move the old VERIFY_xyz interface to that model.  And it's best done at
the end of the merge window when I've done most of my merges, so let's
just get this done once and for all.

This patch was mostly done with a sed-script, with manual fix-ups for
the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.

There were a couple of notable cases:

 - csky still had the old "verify_area()" name as an alias.

 - the iter_iov code had magical hardcoded knowledge of the actual
   values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
   really used it)

 - microblaze used the type argument for a debug printout

but other than those oddities this should be a total no-op patch.

I tried to fix up all architectures, did fairly extensive grepping for
access_ok() uses, and the changes are trivial, but I may have missed
something.  Any missed conversion should be trivially fixable, though.

Signed-off-by: Linus Torvalds

rseq: uapi: Declare rseq_cs field as union, update includes

2018-07-10T20:18:52+00:00

Declaring the rseq_cs field as a union between __u64 and two __u32
allows both 32-bit and 64-bit kernels to read the full __u64, and
therefore validate that a 32-bit user-space cleared the upper 32
bits, thus ensuring a consistent behavior between native 32-bit
kernels and 32-bit compat tasks on 64-bit kernels.

Check that the rseq_cs value read is < TASK_SIZE.

The asm/byteorder.h header needs to be included by rseq.h, now
that it is not using linux/types_32_64.h anymore.

Considering that only __32 and __u64 types are declared in linux/rseq.h,
the linux/types.h header should always be included for both kernel and
user-space code: including stdint.h is just for u64 and u32, which are
not used in this header at all.

Use copy_from_user()/clear_user() to interact with a 64-bit field,
because arm32 does not implement 64-bit __get_user, and ppc32 does not
64-bit get_user. Considering that the rseq_cs pointer does not need to
be loaded/stored with single-copy atomicity from the kernel anymore, we
can simply use copy_from_user()/clear_user().

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Thomas Gleixner 
Cc: linux-api@vger.kernel.org
Cc: Peter Zijlstra 
Cc: "Paul E . McKenney" 
Cc: Boqun Feng 
Cc: Andy Lutomirski 
Cc: Dave Watson 
Cc: Paul Turner 
Cc: Andrew Morton 
Cc: Russell King 
Cc: "H . Peter Anvin" 
Cc: Andi Kleen 
Cc: Chris Lameter 
Cc: Ben Maurer 
Cc: Steven Rostedt 
Cc: Josh Triplett 
Cc: Linus Torvalds 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Michael Kerrisk 
Cc: Joel Fernandes 
Cc: "Paul E. McKenney" 
Cc: "H. Peter Anvin" 
Link: https://lkml.kernel.org/r/20180709195155.7654-5-mathieu.desnoyers@efficios.com