Hi,
Here are a few small patches to fix kernel module loading in the PCuABI kernel [1].
(Sorry about the delay!) There are some notes on testing in the third patch.
Thanks,
Kristina
[1] https://git.morello-project.org/morello/kernel/linux/-/issues/41
Kristina Martsenko (3):
module: Allow arch overrides for ELF arch check
arm64: elf: Enable module loading for PCuABI kernels
arm64: morello: Add test modules to defconfig
.../configs/morello_transitional_pcuabi_defconfig | 6 ++++++
arch/arm64/include/asm/elf.h | 10 ++--------
include/linux/moduleloader.h | 4 ++++
kernel/module/main.c | 2 +-
4 files changed, 13 insertions(+), 9 deletions(-)
base-commit: 7f84d159d4eb989bf2f42d2e3b27a204cb3c1ec4
--
2.25.1
Hi,
This series introduces new user_ptr helpers to help in certain
uaccess-related situations. This is a follow-up to my previous series
"New CHERI API and separation of root capabilities"; the CHERI helpers
it introduced are used to implement the new generic user_ptr helpers in
PCuABI.
The new helpers are (see patch 1 for details):
* make_user_ptr_for_<perms>_uaccess(), to create user pointers in order
to perform uaccess, with appropriate bounds and permissions.
* check_user_ptr_<perms>(), to perform explicit checking of user
pointers.
This series does not actually make use of check_user_ptr_<perms>(),
rather it prepares the ground for implementing explicit checking when
user memory is accessed via kernel mappings [1].
The rest of the series (patch 2-9) is about converting existing uses of
uaddr_to_user_ptr_safe(), as it should now only be used for *providing*
user pointers to userspace, and not for uaccess.
After this series, the only remaining users of uaddr_to_user_ptr_safe()
are:
- fs/binfmt_elf.c to provide all the initial capabilities (stack,
AT_CHERI_*_CAP, etc.). uaddr_to_user_ptr_safe() is still used to write
the initial data on the stack too; it didn't seem worthwhile to
refactor this code as it is going to change anyway as part of [2]
and [3].
- mmap / mremap / shmat to return a valid capability.
To clarify which helper should be used in which situation, here are two
tables specifying the helper to use depending on whether the address is
specified by userspace or the kernel itself, and whether the pointer is
provided to userspace or used by the kernel itself.
*Before* this series:
+-----------------------------------+---------------------+--------------------------+
| Pointer for \ Address provided by | User | Kernel |
+===================================+=====================+==========================+
| User | - | uaddr_to_user_ptr_safe() |
+-----------------------------------+---------------------+--------------------------+
| Kernel (uaccess) | uaddr_to_user_ptr() | uaddr_to_user_ptr_safe() |
+-----------------------------------+---------------------+--------------------------+
*After* this series:
+-----------------------------------+---------------------+-------------------------------+
| Pointer for \ Address provided by | User | Kernel |
+===================================+=====================+===============================+
| User | - | uaddr_to_user_ptr_safe() |
+-----------------------------------+---------------------+-------------------------------+
| Kernel (uaccess) | uaddr_to_user_ptr() | make_user_ptr_*_for_uaccess() |
+-----------------------------------+---------------------+-------------------------------+
Eventually both uaddr_to_user_ptr() and uaddr_to_user_ptr_safe() should
disappear, the first thanks to userspace always providing full pointers
and the second being replaced by handcrafted code creating capabilities
in line with the PCuABI spec (whose bounds give access to only the
intended object and potentially padding).
Note that patch 1 and 4 were included in the first RFC of the CHERI API
series [4]. They remain broadly the same, but:
- make_privileged_user_ptr and check_user_ptr() have been renamed, and the
permissions are now specified by calling the right variant of the function
instead of passing a bitfield. They are now called respectively
make_user_ptr_for_<perms>_uaccess() and check_user_ptr_<perms>().
- The user_ptr documentation has been updated accordingly.
- The commit messages have been improved to reflect the overall
intention better.
Review branch:
https://git.morello-project.org/kbrodsky-arm/linux/-/commits/morello/user_p…
Rendered doc:
https://git.morello-project.org/kbrodsky-arm/linux/-/blob/morello/user_ptr_…
Thanks,
Kevin
[1] https://git.morello-project.org/morello/kernel/linux/-/issues/7
[2] https://git.morello-project.org/morello/kernel/linux/-/issues/19
[3] https://git.morello-project.org/morello/kernel/linux/-/issues/22
[4] https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org…
Kevin Brodsky (9):
linux/user_ptr.h: Introduce uaccess-related helpers
fs/binfmt_elf: Create appropriate user pointer for uaccess
coredump: Create appropriate user pointer for uaccess
mm/memory: Create appropriate user pointer for uaccess
Revert "mm/hugetlb: Use appropriate user pointer conversions"
Revert "mm/shmem: Use appropriate user pointer conversions"
audit: Create appropriate user pointer for uaccess
perf: Avoid uaddr_to_user_ptr_safe() for arbitrary user address
arm64: Create appropriate user pointer for uaccess
Documentation/core-api/user_ptr.rst | 100 ++++++++++++++++++----------
arch/arm64/kernel/debug-monitors.c | 3 +-
arch/arm64/kernel/traps.c | 2 +-
fs/binfmt_elf.c | 14 ++--
fs/coredump.c | 4 +-
include/linux/user_ptr.h | 86 ++++++++++++++++++++++--
kernel/auditsc.c | 3 +-
kernel/events/internal.h | 2 +-
lib/user_ptr.c | 46 +++++++++++++
mm/hugetlb.c | 2 +-
mm/memory.c | 2 +-
mm/shmem.c | 2 +-
12 files changed, 216 insertions(+), 50 deletions(-)
--
2.38.1
Hi,
For the sake of clarity, I am starting this new thread to discuss the
interface we should adopt for the check_user_ptr interface, introduced
by the "New user_ptr helpers for uaccess" series [1.1]. This function is
meant to check that the specifier user pointer (capability in PCuABI)
allows a given range to be accessed in a given way. The range is
specified quite naturally by the address of the pointer + a separate
size argument. As to the nature of the access (read and/or write), as
suggested [2.2] during the review of the preliminary RFC, it is
currently specified in the function name itself: check_user_ptr_read(),
check_user_ptr_write(), check_user_ptr_rw().
I believe this is looking pretty good, but Luca's recent explicit check
patch [3] has shown that it is a little inconvenient in the cases where
the nature of the access is only known at runtime, often through an
integer set to either READ or WRITE. This led me to suggest [1.2] to use
these constants as an argument for check_user_ptr too, only to realise
later that it doesn't work, as it is not possible to use them together
(READ | WRITE is meaningless).
The question now is therefore the following: should we go back to
something like in the RFC [2.1], i.e. pass the access type as argument,
introducing a whole new type / constants for the access type? Or should
we stick to [1.1], i.e. the access type in the function name itself. At
this point I would tend to favour the latter option, as there are not so
many situations where the access type is only known at runtime (just 3
so far), but maybe this is short-sighted.
Opinions very welcome!
Thanks,
Kevin
[1.1]
https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org…
[1.2]
https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org…
[2.1]
https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org…
[2.2]
https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org…
[3]
https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org…
