> > > > Add flags to support the shadow call stack sanitizer, both in the > > dynamic and non-dynamic modes. > > > > Right now, the compiler will emit the warning "unknown feature specified > > for `-Ctarget-feature`: `reserve-x18`". However, the compiler still > > passes it to the codegen backend, so the flag will work just fine. Once > > rustc starts recognizing the flag (or provides another way to enable the > > feature), it will stop emitting this warning. See [1] for the relevant > > issue. > > > > Currently, the compiler thinks that the aarch64-unknown-none target > > doesn't support -Zsanitizer=shadow-call-stack, so the build will fail if > > you enable shadow call stack in non-dynamic mode. However, I still think > > it is reasonable to add the flag now, as it will at least fail the build > > when using an invalid configuration, until the Rust compiler is fixed to > > list -Zsanitizer=shadow-call-stack as supported for the target. See [2] > > for the feature request to add this. > > > > I have tested this change with Rust Binder on an Android device using > > CONFIG_DYNAMIC_SCS. Without the -Ctarget-feature=+reserve-x18 flag, the > > phone crashes immediately on boot, and with the flag, the phone appears > > to work normally. > > > > Link: https://github.com/rust-lang/rust/issues/121970 [1] > > Link: https://github.com/rust-lang/rust/issues/121972 [2] > > Signed-off-by: Alice Ryhl <aliceryhl@xxxxxxxxxx> > > --- > > It's not 100% clear to me whether this patch is enough for full SCS > > support in Rust. If there is some issue where this makes things compile > > and work without actually applying SCS to the Rust code, please let me > > know. Is there some way to verify that it is actually working? > > Perhaps you could write a Rust version of the CFI_BACKWARD test in LKDTM? > > Alternatively, the simplest way to verify this is to look at the > disassembly and verify that shadow stack instructions are emitted to > Rust functions too. In case of dynamic SCS, you might need to dump > function memory in a debugger to verify that PAC instructions were > patched correctly. If they're not, the code will just quietly continue > working without using shadow stacks. Was just in the process of doing that: - `paciasp`/`autiasp` pairs are emitted for functions in Rust modules. - Rust modules have no `.init.eh_frame` section, which implies that `module_finalize` is _not_ rewriting the pac insns when SCS is dynamic. - Confirmed that behavior in the debugger (C modules and the C part of the kernel are correctly rewritten, Rust modules execute with `paciasp`/`autiasp` still in place). - Kernel boots just fine with Rust kunit tests, tested with and without dynamic SCS, i.e., on a CPU that supports PAC/BTI and one that does not. - Rust sample modules load and unload without problems as well. - `x18` is indeed not used in the codegen. I guess we might be able to get this working when we tweak the build system to emit the missing section for Rust modules. - Best Valentin > > > This patch raises the question of whether we should change the Rust > > aarch64 support to use a custom target.json specification. If we do > > that, then we can fix both the warning for dynamic SCS and the > > build-failure for non-dynamic SCS without waiting for a new version of > > rustc with the mentioned issues fixed. > > Sure, having a custom target description for the kernel might be > useful for other purposes too. In the meantime: > > Reviewed-by: Sami Tolvanen <samitolvanen@xxxxxxxxxx> > > Sami > >
