History log of /linux-6.15/rust/kernel/uaccess.rs (Results 1 – 8 of 8)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14
# 4e72a62e 17-Mar-2025 Tamir Duberstein <[email protected]>

rust: uaccess: name the correct function

Correctly refer to `reserve` rather than `try_reserve` in a comment. This
comment has been incorrect since inception in commit 1b580e7b9ba2 ("rust:
uaccess:

rust: uaccess: name the correct function

Correctly refer to `reserve` rather than `try_reserve` in a comment. This
comment has been incorrect since inception in commit 1b580e7b9ba2 ("rust:
uaccess: add userspace pointers").

Fixes: 1b580e7b9ba2 ("rust: uaccess: add userspace pointers")
Signed-off-by: Tamir Duberstein <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Charalampos Mitrodimas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...


Revision tags: v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7
# c80dd3fc 07-Jan-2025 Filipe Xavier <[email protected]>

rust: uaccess: generalize userSliceReader to support any Vec

The UserSliceReader::read_all function is currently restricted to use
only Vec with the kmalloc allocator. However, there is no reason fo

rust: uaccess: generalize userSliceReader to support any Vec

The UserSliceReader::read_all function is currently restricted to use
only Vec with the kmalloc allocator. However, there is no reason for
this limitation.

This patch generalizes the function to accept any Vec regardless of the
allocator used.

There's a use-case for a KVVec in Binder to avoid maximum sizes for a
certain array.

Link: https://github.com/Rust-for-Linux/linux/issues/1136
Signed-off-by: Filipe Xavier <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reflowed and slightly reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...


Revision tags: v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11
# 1bae8729 13-Sep-2024 Gary Guo <[email protected]>

rust: map `long` to `isize` and `char` to `u8`

The following FFI types are replaced compared to `core::ffi`:

1. `char` type is now always mapped to `u8`, since kernel uses
`-funsigned-char` on t

rust: map `long` to `isize` and `char` to `u8`

The following FFI types are replaced compared to `core::ffi`:

1. `char` type is now always mapped to `u8`, since kernel uses
`-funsigned-char` on the C code. `core::ffi` maps it to platform
default ABI, which can be either signed or unsigned.

2. `long` is now always mapped to `isize`. It's very common in the
kernel to use `long` to represent a pointer-sized integer, and in
fact `intptr_t` is a typedef of `long` in the kernel. Enforce this
mapping rather than mapping to `i32/i64` depending on platform can
save us a lot of unnecessary casts.

Signed-off-by: Gary Guo <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Moved `uaccess` changes from the next commit, since they were
irrefutable patterns that Rust >= 1.82.0 warns about. Reworded
slightly and reformatted a few documentation comments. Rebased on
top of `rust-next`. Added the removal of two casts to avoid Clippy
warnings. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...


# d072acda 13-Sep-2024 Gary Guo <[email protected]>

rust: use custom FFI integer types

Currently FFI integer types are defined in libcore. This commit creates
the `ffi` crate and asks bindgen to use that crate for FFI integer types
instead of `core::

rust: use custom FFI integer types

Currently FFI integer types are defined in libcore. This commit creates
the `ffi` crate and asks bindgen to use that crate for FFI integer types
instead of `core::ffi`.

This commit is preparatory and no type changes are made in this commit
yet.

Signed-off-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added `rustdoc`, `rusttest` and KUnit tests support. Rebased on top of
`rust-next` (e.g. migrated more `core::ffi` cases). Reworded crate
docs slightly and formatted. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...


# 58eff8e8 04-Oct-2024 Danilo Krummrich <[email protected]>

rust: treewide: switch to the kernel `Vec` type

Now that we got the kernel `Vec` in place, convert all existing `Vec`
users to make use of it.

Reviewed-by: Alice Ryhl <[email protected]>
Reviewe

rust: treewide: switch to the kernel `Vec` type

Now that we got the kernel `Vec` in place, convert all existing `Vec`
users to make use of it.

Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Converted `kasan_test_rust.rs` too, as discussed. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...


# ce1c54fd 18-Sep-2024 Aliet Exposito Garcia <[email protected]>

rust: kernel: move `FromBytes` and `AsBytes` traits to a new `transmute` module

Refactor the `FromBytes` and `AsBytes` traits from `types.rs` into a new
`transmute.rs` module:

- Add `rust/kernel/t

rust: kernel: move `FromBytes` and `AsBytes` traits to a new `transmute` module

Refactor the `FromBytes` and `AsBytes` traits from `types.rs` into a new
`transmute.rs` module:

- Add `rust/kernel/transmute.rs` with the definitions of `FromBytes`
and `AsBytes`.

- Remove the same trait definitions from `rust/kernel/types.rs`.

- Update `rust/kernel/uaccess.rs` to import `AsBytes` and `FromBytes`
from `transmute.rs`.

The traits and their implementations remain unchanged.

Suggested-by: Benno Lossin <[email protected]>
Link: https://github.com/Rust-for-Linux/linux/issues/1117
Signed-off-by: Aliet Exposito Garcia <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Rebased on top of the lints series and slightly reworded. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...


Revision tags: v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2
# b33bf37a 28-May-2024 Alice Ryhl <[email protected]>

rust: uaccess: add typed accessors for userspace pointers

Add safe methods for reading and writing Rust values to and from
userspace pointers.

The C methods for copying to/from userspace use a func

rust: uaccess: add typed accessors for userspace pointers

Add safe methods for reading and writing Rust values to and from
userspace pointers.

The C methods for copying to/from userspace use a function called
`check_object_size` to verify that the kernel pointer is not dangling.
However, this check is skipped when the length is a compile-time
constant, with the assumption that such cases trivially have a correct
kernel pointer.

In this patch, we apply the same optimization to the typed accessors.
For both methods, the size of the operation is known at compile time to
be size_of of the type being read or written. Since the C side doesn't
provide a variant that skips only this check, we create custom helpers
for this purpose.

The majority of reads and writes to userspace pointers in the Rust
Binder driver uses these accessor methods. Benchmarking has found that
skipping the `check_object_size` check makes a big difference for the
cases being skipped here. (And that the check doesn't make a difference
for the cases that use the raw read/write methods.)

This code is based on something that was originally written by Wedson on
the old rust branch. It was modified by Alice to skip the
`check_object_size` check, and to update various comments, including the
notes about kernel pointers in `WritableToBytes`.

Co-developed-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Reviewed-by: Trevor Gross <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Wrapped docs to 100 and added a few intra-doc links. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...


# 1b580e7b 28-May-2024 Wedson Almeida Filho <[email protected]>

rust: uaccess: add userspace pointers

A pointer to an area in userspace memory, which can be either read-only
or read-write.

All methods on this struct are safe: attempting to read or write on bad

rust: uaccess: add userspace pointers

A pointer to an area in userspace memory, which can be either read-only
or read-write.

All methods on this struct are safe: attempting to read or write on bad
addresses (either out of the bound of the slice or unmapped addresses)
will return `EFAULT`. Concurrent access, *including data races to/from
userspace memory*, is permitted, because fundamentally another userspace
thread/process could always be modifying memory at the same time (in the
same way that userspace Rust's `std::io` permits data races with the
contents of files on disk). In the presence of a race, the exact byte
values read/written are unspecified but the operation is well-defined.
Kernelspace code should validate its copy of data after completing a
read, and not expect that multiple reads of the same address will return
the same value.

These APIs are designed to make it difficult to accidentally write
TOCTOU bugs. Every time you read from a memory location, the pointer is
advanced by the length so that you cannot use that reader to read the
same memory location twice. Preventing double-fetches avoids TOCTOU
bugs. This is accomplished by taking `self` by value to prevent
obtaining multiple readers on a given `UserSlice`, and the readers only
permitting forward reads. If double-fetching a memory location is
necessary for some reason, then that is done by creating multiple
readers to the same memory location.

Constructing a `UserSlice` performs no checks on the provided address
and length, it can safely be constructed inside a kernel thread with no
current userspace process. Reads and writes wrap the kernel APIs
`copy_from_user` and `copy_to_user`, which check the memory map of the
current process and enforce that the address range is within the user
range (no additional calls to `access_ok` are needed).

This code is based on something that was originally written by Wedson on
the old rust branch. It was modified by Alice by removing the
`IoBufferReader` and `IoBufferWriter` traits, and various other changes.

Signed-off-by: Wedson Almeida Filho <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Trevor Gross <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Co-developed-by: Alice Ryhl <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Wrapped docs to 100 and added a few intra-doc links. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...