pm24.git/rust, branch rust-6.12

rust: cfi: add support for CFI_CLANG with Rust

2024-09-16T15:29:58Z

Make it possible to use the Control Flow Integrity (CFI) sanitizer when Rust is enabled. Enabling CFI with Rust requires that CFI is configured to normalize integer types so that all integer types of the same size and signedness are compatible under CFI. Rust and C use the same LLVM backend for code generation, so Rust KCFI is compatible with the KCFI used in the kernel for C. In the case of FineIBT, CFI also depends on -Zpatchable-function-entry for rewriting the function prologue, so we set that flag for Rust as well. The flag for FineIBT requires rustc 1.80.0 or later, so include a Kconfig requirement for that. Enabling Rust will select CFI_ICALL_NORMALIZE_INTEGERS because the flag is required to use Rust with CFI. Using select rather than `depends on` avoids the case where Rust is not visible in menuconfig due to CFI_ICALL_NORMALIZE_INTEGERS not being enabled. One disadvantage of select is that RUST must `depends on` all of the things that CFI_ICALL_NORMALIZE_INTEGERS depends on to avoid invalid configurations. Alice has been using KCFI on her phone for several months, so it is reasonably well tested on arm64. Signed-off-by: Matthew Maurer Co-developed-by: Alice Ryhl Signed-off-by: Alice Ryhl Reviewed-by: Sami Tolvanen Tested-by: Gatlin Newhouse Acked-by: Kees Cook Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20240801-kcfi-v2-2-c93caed3d121@google.com [ Replaced `!FINEIBT` requirement with `!CALL_PADDING` to prevent a build error on older Rust compilers. Fixed typo. - Miguel ] Signed-off-by: Miguel Ojeda

kbuild: rust: replace proc macros dependency on `core.o` with the version text

2024-09-05T20:44:51Z

With the `RUSTC_VERSION_TEXT` rebuild support in place, now proc macros can depend on that instead of `core.o`. This means that both the `core` and `macros` crates can be built in parallel, and that touching `core.o` does not trigger a rebuild of the proc macros. This could be accomplished using the same approach as for `core` (i.e. depending directly on `include/config/RUSTC_VERSION_TEXT`). However, that is considered an implementation detail [1], and thus it is best to avoid it. Instead, let fixdep find a string that we explicitly write down in the source code for this purpose (like it is done for `include/linux/compiler-version.h`), which we can easily do (unlike for `core`) since this is our own source code. Suggested-by: Masahiro Yamada Link: https://lore.kernel.org/rust-for-linux/CAK7LNAQBG0nDupXSgAAk-6nOqeqGVkr3H1RjYaqRJ1OxmLm6xA@mail.gmail.com/ [1] Reviewed-by: Nicolas Schier Tested-by: Alice Ryhl Acked-by: Masahiro Yamada Link: https://lore.kernel.org/r/20240902165535.1101978-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda

kbuild: rust: rebuild if the version text changes

2024-09-05T20:44:41Z

Now that `RUSTC_VERSION_TEXT` exists, use it to rebuild `core` when the version text changes (which in turn will trigger a rebuild of all the kernel Rust code). This also applies to proc macros (which only work with the `rustc` that compiled them), via the already existing dependency on `core.o`. That is cleaned up in the next commit. However, this does not cover host programs written in Rust, which is the same case in the C side. This is accomplished by referencing directly the generated file, instead of using the `fixdep` header trick, since we cannot change the Rust standard library sources. This is not too much of a burden, since it only needs to be done for `core`. Tested-by: Alice Ryhl Reviewed-by: Nicolas Schier Acked-by: Masahiro Yamada Link: https://lore.kernel.org/r/20240902165535.1101978-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: avoid `box_uninit_write` feature

2024-09-04T21:11:31Z

Like commit 0903b9e2a46c ("rust: alloc: eschew `Box>::write`"), but for the new `rbtree` and `alloc` code. That is, `feature(new_uninit)` [1] got partially stabilized [2] for Rust 1.82.0 (expected to be released on 2024-10-17), but it did not include `Box>::write`, which got split into `feature(box_uninit_write)` [3]. To avoid relying on a new unstable feature, rewrite the `write` + `assume_init` pair manually. Link: https://github.com/rust-lang/rust/issues/63291 [1] Link: https://github.com/rust-lang/rust/pull/129401 [2] Link: https://github.com/rust-lang/rust/issues/129397 [3] Reviewed-by: Alice Ryhl Reviewed-by: Matt Gilbride Link: https://lore.kernel.org/r/20240904144229.18592-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: rbtree: add `RBTree::entry`

2024-08-31T15:36:20Z

This mirrors the entry API [1] from the Rust standard library on `RBTree`. This API can be used to access the entry at a specific key and make modifications depending on whether the key is vacant or occupied. This API is useful because it can often be used to avoid traversing the tree multiple times. This is used by binder to look up and conditionally access or insert a value, depending on whether it is there or not [2]. Link: https://doc.rust-lang.org/stable/std/collections/btree_map/enum.Entry.html [1] Link: https://android-review.googlesource.com/c/kernel/common/+/2849906 [2] Signed-off-by: Alice Ryhl Tested-by: Alice Ryhl Reviewed-by: Boqun Feng Reviewed-by: Benno Lossin Signed-off-by: Matt Gilbride Link: https://lore.kernel.org/r/20240822-b4-rbtree-v12-5-014561758a57@google.com Signed-off-by: Miguel Ojeda

rust: rbtree: add cursor

2024-08-31T15:36:20Z

Add a cursor interface to `RBTree`, supporting the following use cases: - Inspect the current node pointed to by the cursor, inspect/move to it's neighbors in sort order (bidirectionally). - Mutate the tree itself by removing the current node pointed to by the cursor, or one of its neighbors. Add functions to obtain a cursor to the tree by key: - The node with the smallest key - The node with the largest key - The node matching the given key, or the one with the next larger key The cursor abstraction is needed by the binder driver to efficiently search for nodes and (conditionally) modify them, as well as their neighbors [1]. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-6-08ba9197f637@google.com/ [1] Co-developed-by: Alice Ryhl Signed-off-by: Alice Ryhl Tested-by: Alice Ryhl Reviewed-by: Boqun Feng Reviewed-by: Benno Lossin Signed-off-by: Matt Gilbride Link: https://lore.kernel.org/r/20240822-b4-rbtree-v12-4-014561758a57@google.com Signed-off-by: Miguel Ojeda

rust: rbtree: add mutable iterator

2024-08-31T15:36:19Z

Add mutable Iterator implementation for `RBTree`, allowing iteration over (key, value) pairs in key order. Only values are mutable, as mutating keys implies modifying a node's position in the tree. Mutable iteration is used by the binder driver during shutdown to clean up the tree maintained by the "range allocator" [1]. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-6-08ba9197f637@google.com/ [1] Signed-off-by: Wedson Almeida Filho Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Reviewed-by: Boqun Feng Reviewed-by: Benno Lossin Signed-off-by: Matt Gilbride Link: https://lore.kernel.org/r/20240822-b4-rbtree-v12-3-014561758a57@google.com Signed-off-by: Miguel Ojeda

rust: rbtree: add iterator

2024-08-31T15:36:19Z

- Add Iterator implementation for `RBTree`, allowing iteration over (key, value) pairs in key order. - Add individual `keys()` and `values()` functions to iterate over keys or values alone. - Update doctests to use iteration instead of explicitly getting items. Iteration is needed by the binder driver to enumerate all values in a tree for oneway spam detection [1]. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-17-08ba9197f637@google.com/ [1] Signed-off-by: Wedson Almeida Filho Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Reviewed-by: Benno Lossin Reviewed-by: Boqun Feng Signed-off-by: Matt Gilbride Link: https://lore.kernel.org/r/20240822-b4-rbtree-v12-2-014561758a57@google.com Signed-off-by: Miguel Ojeda

rust: rbtree: add red-black tree implementation backed by the C version

2024-08-31T15:35:08Z

The rust rbtree exposes a map-like interface over keys and values, backed by the kernel red-black tree implementation. Values can be inserted, deleted, and retrieved from a `RBTree` by key. This base abstraction is used by binder to store key/value pairs and perform lookups, for example the patch "[PATCH RFC 03/20] rust_binder: add threading support" in the binder RFC [1]. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-3-08ba9197f637@google.com/ [1] Signed-off-by: Wedson Almeida Filho Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Reviewed-by: Boqun Feng Reviewed-by: Benno Lossin Signed-off-by: Matt Gilbride Link: https://lore.kernel.org/r/20240822-b4-rbtree-v12-1-014561758a57@google.com [ Updated link to docs.kernel.org. - Miguel ] Signed-off-by: Miguel Ojeda

rust: enable rustdoc's `--generate-link-to-definition`

2024-08-25T16:37:40Z

In Rust 1.56.0 [1], rustdoc introduced the "jump to definition" feature [2], i.e. the unstable flag `--generate-link-to-definition`. It adds links to the source view of the documentation. For instance, in the source view of `rust/kernel/sync.rs`, for this code: impl Default for LockClassKey { fn default() -> Self { Self::new() } } It will add three hyperlinks: - `Default` points to the rendered "Trait `core::default::Default`" page (not the source view, since it goes to another crate, though this may change). - `LockClassKey` points to the `pub struct LockClassKey(...);` line in the same page, highlighting the line number. - `Self::new()` points to the `pub const fn new() -> Self { ... }` associated function, highlighting its line numbers (i.e. for the full function). This makes the source view more useful and a bit closer to the experience in e.g. the Elixir Cross Referencer [3]. I have provisionally enabled it for rust.docs.kernel.org [4] -- one can take a look at the source view there for an example of how it looks like. Thus enable it. Cc: Guillaume Gomez Link: https://github.com/rust-lang/rust/pull/84176 [1] Link: https://github.com/rust-lang/rust/issues/89095 [2] Link: https://elixir.bootlin.com [3] Link: https://rust.docs.kernel.org [4] Reviewed-by: Gary Guo Link: https://lore.kernel.org/r/20240818141249.387166-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda