linux.git/arch/riscv/kernel/process.c, branch v6.5

riscv: Add prctl controls for userspace vector management

2023-06-08T14:16:53+00:00

This patch add two riscv-specific prctls, to allow usespace control the
use of vector unit:

 * PR_RISCV_V_SET_CONTROL: control the permission to use Vector at next,
   or all following execve for a thread. Turning off a thread's Vector
   live is not possible since libraries may have registered ifunc that
   may execute Vector instructions.
 * PR_RISCV_V_GET_CONTROL: get the same permission setting for the
   current thread, and the setting for following execve(s).

Signed-off-by: Andy Chiu 
Reviewed-by: Greentime Hu 
Reviewed-by: Vincent Chen 
Link: https://lore.kernel.org/r/20230605110724.21391-22-andy.chiu@sifive.com
Signed-off-by: Palmer Dabbelt

riscv: Add task switch support for vector

2023-06-08T14:16:43+00:00

This patch adds task switch support for vector. It also supports all
lengths of vlen.

Suggested-by: Andrew Waterman 
Co-developed-by: Nick Knight 
Signed-off-by: Nick Knight 
Co-developed-by: Guo Ren 
Signed-off-by: Guo Ren 
Co-developed-by: Vincent Chen 
Signed-off-by: Vincent Chen 
Co-developed-by: Ruinland Tsai 
Signed-off-by: Ruinland Tsai 
Signed-off-by: Greentime Hu 
Signed-off-by: Vineet Gupta 
Signed-off-by: Andy Chiu 
Reviewed-by: Conor Dooley 
Reviewed-by: Björn Töpel 
Reviewed-by: Heiko Stuebner 
Tested-by: Heiko Stuebner 
Link: https://lore.kernel.org/r/20230605110724.21391-11-andy.chiu@sifive.com
Signed-off-by: Palmer Dabbelt

riscv: entry: Consolidate ret_from_kernel_thread into ret_from_fork

2023-03-23T15:47:02+00:00

The ret_from_kernel_thread() behaves similarly with ret_from_fork(),
the only difference is whether call the fn(arg) or not, this can be
achieved by testing fn is NULL or not, I.E s0 is 0 or not. Many
architectures have done the same thing, it makes entry.S more clean.

Signed-off-by: Jisheng Zhang 
Reviewed-by: Björn Töpel 
Reviewed-by: Guo Ren 
Tested-by: Guo Ren 
Signed-off-by: Guo Ren 
Link: https://lore.kernel.org/r/20230222033021.983168-7-guoren@kernel.org
Signed-off-by: Palmer Dabbelt

arch/idle: Change arch_cpu_idle() behavior: always exit with IRQs disabled

2023-01-13T10:48:15+00:00

Current arch_cpu_idle() is called with IRQs disabled, but will return
with IRQs enabled.

However, the very first thing the generic code does after calling
arch_cpu_idle() is raw_local_irq_disable(). This means that
architectures that can idle with IRQs disabled end up doing a
pointless 'enable-disable' dance.

Therefore, push this IRQ disabling into the idle function, meaning
that those architectures can avoid the pointless IRQ state flipping.

Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Ingo Molnar 
Tested-by: Tony Lindgren 
Tested-by: Ulf Hansson 
Reviewed-by: Gautham R. Shenoy 
Acked-by: Mark Rutland  [arm64]
Acked-by: Rafael J. Wysocki 
Acked-by: Guo Ren 
Acked-by: Frederic Weisbecker 
Link: https://lore.kernel.org/r/20230112195540.618076436@infradead.org

riscv: process: fix kernel info leakage

2022-11-10T21:43:15+00:00

thread_struct's s[12] may contain random kernel memory content, which
may be finally leaked to userspace. This is a security hole. Fix it
by clearing the s[12] array in thread_struct when fork.

As for kthread case, it's better to clear the s[12] array as well.

Fixes: 7db91e57a0ac ("RISC-V: Task implementation")
Signed-off-by: Jisheng Zhang 
Tested-by: Guo Ren 
Link: https://lore.kernel.org/r/20221029113450.4027-1-jszhang@kernel.org
Reviewed-by: Guo Ren 
Link: https://lore.kernel.org/r/CAJF2gTSdVyAaM12T%2B7kXAdRPGS4VyuO08X1c7paE-n4Fr8OtRA@mail.gmail.com/
Signed-off-by: Palmer Dabbelt

riscv: compat: s/failed/unsupported if compat mode isn't supported

2022-10-06T01:07:17+00:00

When compat mode isn't supported(I believe this is the most case now),
kernel will emit somthing as:
[    0.050407] riscv: ELF compat mode failed

This msg may make users think there's something wrong with the kernel
itself, replace "failed" with "unsupported" to make it clear. In fact
this is the real compat_mode_supported meaning. After the patch, the
msg would be:
[    0.050407] riscv: ELF compat mode unsupported

Signed-off-by: Jisheng Zhang 
Acked-by: Guo Ren 
Link: https://lore.kernel.org/r/20220821141819.3804-1-jszhang@kernel.org/
Signed-off-by: Palmer Dabbelt

Merge tag 'kthread-cleanups-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace

2022-06-03T23:03:05+00:00

Pull kthread updates from Eric Biederman:
 "This updates init and user mode helper tasks to be ordinary user mode
  tasks.

  Commit 40966e316f86 ("kthread: Ensure struct kthread is present for
  all kthreads") caused init and the user mode helper threads that call
  kernel_execve to have struct kthread allocated for them. This struct
  kthread going away during execve in turned made a use after free of
  struct kthread possible.

  Here, commit 343f4c49f243 ("kthread: Don't allocate kthread_struct for
  init and umh") is enough to fix the use after free and is simple
  enough to be backportable.

  The rest of the changes pass struct kernel_clone_args to clean things
  up and cause the code to make sense.

  In making init and the user mode helpers tasks purely user mode tasks
  I ran into two complications. The function task_tick_numa was
  detecting tasks without an mm by testing for the presence of
  PF_KTHREAD. The initramfs code in populate_initrd_image was using
  flush_delayed_fput to ensuere the closing of all it's file descriptors
  was complete, and flush_delayed_fput does not work in a userspace
  thread.

  I have looked and looked and more complications and in my code review
  I have not found any, and neither has anyone else with the code
  sitting in linux-next"

* tag 'kthread-cleanups-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
  sched: Update task_tick_numa to ignore tasks without an mm
  fork: Stop allowing kthreads to call execve
  fork: Explicitly set PF_KTHREAD
  init: Deal with the init process being a user mode process
  fork: Generalize PF_IO_WORKER handling
  fork: Explicity test for idle tasks in copy_thread
  fork: Pass struct kernel_clone_args into copy_thread
  kthread: Don't allocate kthread_struct for init and umh

fork: Generalize PF_IO_WORKER handling

2022-05-07T14:01:59+00:00

Add fn and fn_arg members into struct kernel_clone_args and test for
them in copy_thread (instead of testing for PF_KTHREAD | PF_IO_WORKER).
This allows any task that wants to be a user space task that only runs
in kernel mode to use this functionality.

The code on x86 is an exception and still retains a PF_KTHREAD test
because x86 unlikely everything else handles kthreads slightly
differently than user space tasks that start with a function.

The functions that created tasks that start with a function
have been updated to set ".fn" and ".fn_arg" instead of
".stack" and ".stack_size".  These functions are fork_idle(),
create_io_thread(), kernel_thread(), and user_mode_thread().

Link: https://lkml.kernel.org/r/20220506141512.516114-4-ebiederm@xmission.com
Signed-off-by: "Eric W. Biederman"

fork: Pass struct kernel_clone_args into copy_thread

2022-05-07T14:01:48+00:00

With io_uring we have started supporting tasks that are for most
purposes user space tasks that exclusively run code in kernel mode.

The kernel task that exec's init and tasks that exec user mode
helpers are also user mode tasks that just run kernel code
until they call kernel execve.

Pass kernel_clone_args into copy_thread so these oddball
tasks can be supported more cleanly and easily.

v2: Fix spelling of kenrel_clone_args on h8300
Link: https://lkml.kernel.org/r/20220506141512.516114-2-ebiederm@xmission.com
Signed-off-by: "Eric W. Biederman"

riscv: compat: Add hw capability check for elf

2022-04-26T20:36:47+00:00

Detect hardware COMPAT (32bit U-mode) capability in rv64. If not
support COMPAT mode in hw, compat_elf_check_arch would return
false by compat_binfmt_elf.c

Add CLASS to enhance (compat_)elf_check_arch to distinguish
32BIT/64BIT elf.

Signed-off-by: Guo Ren 
Signed-off-by: Guo Ren 
Tested-by: Heiko Stuebner 
Link: https://lore.kernel.org/r/20220405071314.3225832-16-guoren@kernel.org
Signed-off-by: Palmer Dabbelt