pm24.git, branch rust-6.12

kasan: rust: Add KASAN smoke test via UAF

2024-09-16T16:04:37Z

Adds a smoke test to ensure that KASAN in Rust is actually detecting a Rust-native UAF. There is significant room to expand this test suite, but this will at least ensure that flags are having the intended effect. The rename from kasan_test.c to kasan_test_c.c is in order to allow the single kasan_test.ko test suite to contain both a .o file produced by the C compiler and one produced by rustc. Signed-off-by: Matthew Maurer Reviewed-by: Andrey Konovalov Link: https://lore.kernel.org/r/20240820194910.187826-5-mmaurer@google.com [ Applied empty line nit, removed double empty line, applied `rustfmt` and formatted crate comment. - Miguel ] Signed-off-by: Miguel Ojeda

kbuild: rust: Enable KASAN support

2024-09-16T16:04:37Z

Rust supports KASAN via LLVM, but prior to this patch, the flags aren't set properly. Suggested-by: Miguel Ojeda Signed-off-by: Matthew Maurer Reviewed-by: Andrey Konovalov Link: https://lore.kernel.org/r/20240820194910.187826-4-mmaurer@google.com [ Applied "SW_TAGS KASAN" nit. - Miguel ] Signed-off-by: Miguel Ojeda

rust: kasan: Rust does not support KHWASAN

2024-09-16T16:04:37Z

Rust does not yet have support for software tags. Prevent RUST from being selected if KASAN_SW_TAGS is enabled. Signed-off-by: Matthew Maurer Reviewed-by: Andrey Konovalov Link: https://lore.kernel.org/r/20240820194910.187826-3-mmaurer@google.com Signed-off-by: Miguel Ojeda

kbuild: rust: Define probing macros for rustc

2024-09-16T16:04:37Z

Creates flag probe macro variants for `rustc`. These are helpful because: 1. The kernel now supports a minimum `rustc` version rather than a single version. 2. `rustc` links against a range of LLVM revisions, occasionally even ones without an official release number. Since the availability of some Rust flags depends on which LLVM it has been linked against, probing is necessary. Signed-off-by: Matthew Maurer Link: https://github.com/Rust-for-Linux/linux/pull/1087 Link: https://lore.kernel.org/r/20240820194910.187826-2-mmaurer@google.com Signed-off-by: Miguel Ojeda

kasan: simplify and clarify Makefile

2024-09-16T16:04:32Z

When KASAN support was being added to the Linux kernel, GCC did not yet support all of the KASAN-related compiler options. Thus, the KASAN Makefile had to probe the compiler for supported options. Nowadays, the Linux kernel GCC version requirement is 5.1+, and thus we don't need the probing of the -fasan-shadow-offset parameter: it exists in all 5.1+ GCCs. Simplify the KASAN Makefile to drop CFLAGS_KASAN_MINIMAL. Also add a few more comments and unify the indentation. Signed-off-by: Andrey Konovalov Acked-by: Marco Elver Link: https://lore.kernel.org/r/20240814161052.10374-1-andrey.konovalov@linux.dev Signed-off-by: Miguel Ojeda

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

cfi: add CONFIG_CFI_ICALL_NORMALIZE_INTEGERS

2024-09-12T22:43:55Z

Introduce a Kconfig option for enabling the experimental option to normalize integer types. This ensures that integer types of the same size and signedness are considered compatible by the Control Flow Integrity sanitizer. The security impact of this flag is minimal. When Sami Tolvanen looked into it, he found that integer normalization reduced the number of unique type hashes in the kernel by ~1%, which is acceptable. This option exists for compatibility with Rust, as C and Rust do not have the same set of integer types. There are cases where C has two different integer types of the same size and signedness, but Rust only has one integer type of that size and signedness. When Rust calls into C functions using such types in their signature, this results in CFI failures. One example is 'unsigned long long' and 'unsigned long' which are both 64-bit on LP64 targets, so on those targets this flag will give both types the same CFI tag. This flag changes the ABI heavily. It is not applied automatically when CONFIG_RUST is turned on to make sure that the CONFIG_RUST option does not change the ABI of C code. For example, some build may need to make other changes atomically with toggling this flag. Having it be a separate option makes it possible to first turn on normalized integer tags, and then later turn on CONFIG_RUST. Similarly, when turning on CONFIG_RUST in a build, you may need a few attempts where the RUST=y commit gets reverted a few times. It is inconvenient if reverting RUST=y also requires reverting the changes you made to support normalized integer tags. To avoid having this flag impact builds that don't care about this, the next patch in this series will make CONFIG_RUST turn on this option using `select` rather than `depends on`. 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-1-c93caed3d121@google.com Signed-off-by: Miguel Ojeda

rust: support for shadow call stack sanitizer

2024-09-12T22:03:14Z

Add all of the flags that are needed to support the shadow call stack (SCS) sanitizer with Rust, and updates Kconfig to allow only configurations that work. The -Zfixed-x18 flag is required to use SCS on arm64, and requires rustc version 1.80.0 or greater. This restriction is reflected in Kconfig. When CONFIG_DYNAMIC_SCS is enabled, the build will be configured to include unwind tables in the build artifacts. Dynamic SCS uses the unwind tables at boot to find all places that need to be patched. The -Cforce-unwind-tables=y flag ensures that unwind tables are available for Rust code. In non-dynamic mode, the -Zsanitizer=shadow-call-stack flag is what enables the SCS sanitizer. Using this flag requires rustc version 1.82.0 or greater on the targets used by Rust in the kernel. This restriction is reflected in Kconfig. It is possible to avoid the requirement of rustc 1.80.0 by using -Ctarget-feature=+reserve-x18 instead of -Zfixed-x18. However, this flag emits a warning during the build, so this patch does not add support for using it and instead requires 1.80.0 or greater. The dependency is placed on `select HAVE_RUST` to avoid a situation where enabling Rust silently turns off the sanitizer. Instead, turning on the sanitizer results in Rust being disabled. We generally do not want changes to CONFIG_RUST to result in any mitigations being changed or turned off. At the time of writing, rustc 1.82.0 only exists via the nightly release channel. There is a chance that the -Zsanitizer=shadow-call-stack flag will end up needing 1.83.0 instead, but I think it is small. Reviewed-by: Sami Tolvanen Reviewed-by: Ard Biesheuvel Reviewed-by: Kees Cook Acked-by: Will Deacon Signed-off-by: Alice Ryhl Link: https://lore.kernel.org/r/20240829-shadow-call-stack-v7-1-2f62a4432abf@google.com [ Fixed indentation using spaces. - Miguel ] Signed-off-by: Miguel Ojeda

docs: rust: include other expressions in conditional compilation section

2024-09-05T20:45:01Z

Expand the conditional compilation section to explain how to support other expressions, such as testing whether `RUSTC_VERSION` is at least a given version, which requires a numerical comparison that Rust's `cfg` predicates do not support (yet?). Reviewed-by: Nicolas Schier Tested-by: Alice Ryhl Acked-by: Masahiro Yamada Link: https://lore.kernel.org/r/20240902165535.1101978-7-ojeda@kernel.org 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