linux-toradex.git/kernel/rseq.c, branch v5.12-rc5

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

rseq: uapi: Update uapi comments

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

Update rseq uapi header comments to reflect that user-space need to do
thread-local loads/stores from/to the struct rseq fields.

As a consequence of this added requirement, the kernel does not need
to perform loads/stores with single-copy atomicity.

Update the comment associated to the "flags" fields to describe
more accurately that it's only useful to facilitate single-stepping
through rseq critical sections with debuggers.

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-4-mathieu.desnoyers@efficios.com

rseq: Use get_user/put_user rather than __get_user/__put_user

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

__get_user()/__put_user() is used to read values for address ranges that
were already checked with access_ok() on rseq registration.

It has been recognized that __get_user/__put_user are optimizing the
wrong thing. Replace them by get_user/put_user across rseq instead.

If those end up showing up in benchmarks, the proper approach would be to
use user_access_begin() / unsafe_{get,put}_user() / user_access_end()
anyway.

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: linux-arm-kernel@lists.infradead.org
Link: https://lkml.kernel.org/r/20180709195155.7654-3-mathieu.desnoyers@efficios.com

rseq: Use __u64 for rseq_cs fields, validate user inputs

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

Change the rseq ABI so rseq_cs start_ip, post_commit_offset and abort_ip
fields are seen as 64-bit fields by both 32-bit and 64-bit kernels rather
that ignoring the 32 upper bits on 32-bit kernels. This ensures we have a
consistent behavior for a 32-bit binary executed on 32-bit kernels and in
compat mode on 64-bit kernels.

Validating the value of abort_ip field to be below TASK_SIZE ensures the
kernel don't return to an invalid address when returning to userspace
after an abort. I don't fully trust each architecture code to consistently
deal with invalid return addresses.

Validating the value of the start_ip and post_commit_offset fields
prevents overflow on arithmetic performed on those values, used to
check whether abort_ip is within the rseq critical section.

If validation fails, the process is killed with a segmentation fault.

When the signature encountered before abort_ip does not match the expected
signature, return -EINVAL rather than -EPERM to be consistent with other
input validation return codes from rseq_get_rseq_cs().

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-2-mathieu.desnoyers@efficios.com