Received-SPF: pass (google.com: domain of linux-kernel+bounces-91413-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Valentin Obst <kernel@valentinobst.de>
To: samitolvanen@google.com,
	aliceryhl@google.com
Cc: Jamie.Cunliffe@arm.com,
	a.hindborg@samsung.com,
	alex.gaynor@gmail.com,
	ardb@kernel.org,
	benno.lossin@proton.me,
	bjorn3_gh@protonmail.com,
	boqun.feng@gmail.com,
	broonie@kernel.org,
	catalin.marinas@arm.com,
	gary@garyguo.net,
	keescook@chromium.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kbuild@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	mark.rutland@arm.com,
	masahiroy@kernel.org,
	maz@kernel.org,
	nathan@kernel.org,
	ndesaulniers@google.com,
	nicolas@fjasle.eu,
	ojeda@kernel.org,
	rust-for-linux@vger.kernel.org,
	wedsonaf@gmail.com,
	will@kernel.org,
	Valentin Obst <kernel@valentinobst.de>
Subject: Re: [PATCH] rust: add flags for shadow call stack sanitizer
Date: Tue,  5 Mar 2024 00:31:51 +0100
Message-ID: <20240304233151.248925-1-kernel@valentinobst.de>
In-Reply-To: <CABCJKuem3GbLO-G7+wi8LPA8rFgNzFVjNof7zcAO1UGJR4u44Q@mail.gmail.com>
References: <CABCJKuem3GbLO-G7+wi8LPA8rFgNzFVjNof7zcAO1UGJR4u44Q@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
UI-OutboundReport: notjunk:1;M01:P0:ru6A4YDERCw=;+bZWKXS1YRbH7TB3hkKFx2wddro
 Yp7mUqdCPFrvVq360nLeRonyxaMf/ejvKrPM8HAfGJOGqu+Hbp/whpdY2qVYRx9lBqJhZnE1E
 6w0fSZOBM2RogHQChGIB71pB8yczl+BvZIrruW4Zzww7FUK5JKuk5GHwnCNWb+eq8KJEQ8JEE
 xFkuS3d04MhlorRAYlqANMX8ooWytWe3nOoVywEv5apGNyZHTCWaUgnsW4pDJoS6x6EO1CwhH
 jlpbSIR9al35VmO7hmU/NdT2EJQkqSpqQqXkRtTcNqpNl5HX/ux07bRvsgfLLD9ej6io+jzth
 EGBCL+bFYryPrZjql/I6y22bZR14tDzEVESGyKOFBWip3nr+MRjygEQeOuoouGa6Wzo8lFsDs
 CH8++7MSr8mITtBfrWdI8JzPTztIdikxX7caBu1rqAAzRQ70slZ/Xps/MZhv8kgr3fR8P9wHe
 V3heKZh6KFBPFmg4uMAWLcKmc7y6jEoup9IifXpPYaaQ2PK6l6/mUjWUSoSsziP6Vhcs+4cph
 HW3gWwUxUXL31CjgJxfftk8Lr7XYnmghHGbbDtkHUj392N5OssVNZ7tXNAyiwQs7GgIY1KcWw
 VF7YeeBtwLmB+Uy4mXGBaW0e8eOoe9dtwsnX2+snl2xP1S7jG1/yZbDZ5IqRVjWtMFtm1+elO
 3DnzZEZqDfLLEuKxJkncsOA8xKwHILPnJ8jj64jZVhDlT8sSIP8UgaalgdskJEDDGTE6VLmB2
 xyzVHsefUn3LQet3Mm9twRsRZ+Fm5hJNDFJStEPwx6nDFx5cFRJHfA=

> >
> > 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@google.com>
> > ---
> > 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@google.com>
>
> Sami
>
>