On Tue, Mar 5, 2024 at 12:32 AM Valentin Obst <kernel@xxxxxxxxxxxxxxx> wrote: > > > > > > > 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. I suppose the -Cforce-unwind-tables=y flag will most likely do it. There's also an use_sync_unwind option, but it defaults to no, so it doesn't seem like we need to set it. Alice
