security: hardware cfi ("landing pads") support

[enh-google]

if https://github.com/riscv/riscv-cfi lands early enough, we'll want that as part of the ABI. even if it doesn't, we'll want to support it and enable it by default for the kernel and OS.

[samitolvanen]

Kernel patches for U-mode Zisslpcfi support: https://lore.kernel.org/lkml/[email protected]/

Note that for fine-grained forward-edge CFI we'll still need the compiler to emit landing pad tags.

[appujee]

See the comment below ~Currently there are two blockers to CFI proposal~ ~- depends on Zimop~ ~- https://wiki.riscv.org/display/HOME/Specification+Status~ ~- https://docs.google.com/spreadsheets/d/1SwjOz0xJBrbiwggh7MiwfWF5f-0zY9mjXYd51U0MJog/edit~ ~- cfi extension for landing pads~

[deepak0414]

I would edit above comment to

Support for Zisslpcfi based CFI in android-riscv64 would be dependent on

Spec ratification dependencies

• Ratification of zimops spec
• Ratification of Zisslpcfi spec

Software dependencies

• Support for U mode shadow stack and landing pad in toolchain (gcc and llvm)
• Support for U mode shadow stack and landing pad in linux kernel
• Support for shadow stack and landing pad in libc (glibc. If android uses different libc then mention that)

[samitolvanen]

A lot has changed here since the previous comments. Landing pads were split into the Zicfilp extension, which no longer uses Zimops, and the lpad instruction is now in HINT space with the goal of making Zicfilp enabled programs compatible with non-Zicfilp hardware.

Unfortunately, it doesn't look like the latest spec has an option to disable Zicfilp per application (or even better, per page), it can only be disabled for the entire privilege mode, which creates a different set of problems. Specifically, if we want to enable Zicfilp in Android:

1. We must have landing pads in all userspace binaries from the beginning. Otherwise, it's going to be challenging to enable the feature later without breaking compatibility with existing apps that don't have landing pads.
2. We're going to be stuck with ARM BTI style coarse-grained CFI, because ensuring all userspace software works with fine-grained CFI is not feasible. For components where we actually want to use fine-grained CFI, we'll presumably need a separate set of libraries that also use fine-grained CFI.

On the compiler side, I see LLVM recently added MC layer support for Zicfilp, which simply adds support for the lpad instruction: https://reviews.llvm.org/rG818e76d6f2dd90362e71e84f492c167958ef3257 So far it doesn't look like anyone has submitted patches to actually emit these instructions as part of a CFI scheme.

[samitolvanen]

We must have landing pads in all userspace binaries from the beginning. Otherwise, it's going to be challenging to enable the feature later without breaking compatibility with existing apps that don't have landing pads.

Ved kindly explained to me that the idea is for the kernel to disable Zicfilp when context switching to a process that hasn't declared support for the extension. This also disables the extension for any libraries loaded into the process, so ideally we would still enable landing pads from the beginning, but at least it should be possible to enable the extension in other processes.