On Tue, Mar 5, 2024 at 12:31 PM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote: > > On Tue, Mar 5, 2024 at 12:28 PM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote: > > > > On Tue, Mar 5, 2024 at 12:20 PM Valentin Obst <kernel@xxxxxxxxxxxxxxx> wrote: > > > > > > > >>> 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. > > > > > > Yes, enabling this means that `.eh_frame` sections, which are converted to > > > `.init.eh_frame` sections for loadable modules, are generated for Rust > > > objects. > > > > > > Tested booting, kunit tests, sample modules (as builtin and loadable) for > > > both, dynamic SCS active and inactive. Backtraces on Rust panicks also look > > > normal. > > > > > > Confirmed that in the debugger that builtin and external modules are > > > rewritten (or not rewritten if no dynamic SCS). Did not check that the > > > `eh_frame` sections are exhaustive, i.e., cover all `paciasp`/`autiasp` > > > pairs, only verified a few functions (in init text and normal text). > > > > Thank you for checking that! > > > > > > There's also an use_sync_unwind option, but it defaults to no, so it > > > > doesn't seem like we need to set it. > > > > > > Are those defaults stable or will we notice if they change? If not it might > > > make sense to set it explicitly anyways to avoid surprises in the future. > > > > The flag itself is unstable, so I imagine that nothing is promised about it. > > > > I tried it, but I wasn't actually able to find a way to set it. I can > > see the flag in the rustc source code, but passing -Zuse-sync-unwind=n > > results in "error: unknown unstable option: `use-sync-unwind`". Not > > sure what the issue is. > > Oh, I understand now. It's really recent and not in 1.73.0, which is > what I'm using in the Android build. Sent v2 with what we have learned: https://lore.kernel.org/rust-for-linux/20240305-shadow-call-stack-v2-1-c7b4a3f4d616@xxxxxxxxxx/ Thanks!
