|
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 ...
|