Message ID | cover.1710446682.git.ptosi@google.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: arm64: Add support for hypervisor kCFI | expand |
Hi Pierre-Clément, On Thu, 14 Mar 2024 20:23:00 +0000, Pierre-Clément Tosi <ptosi@google.com> wrote: > > CONFIG_CFI_CLANG ("kernel Control Flow Integrity") makes the compiler inject > runtime type checks before any indirect function call. On AArch64, it generates > a BRK instruction to be executed on type mismatch and encodes the indices of the > registers holding the branch target and expected type in the immediate of the > instruction. As a result, a synchronous exception gets triggered on kCFI failure > and the fault handler can retrieve the immediate (and indices) from ESR_ELx. > > This feature has been supported at EL1 ("host") since it was introduced by > b26e484b8bb3 ("arm64: Add CFI error handling"), where cfi_handler() decodes > ESR_EL1, giving informative panic messages such as > > [ 21.885179] CFI failure at lkdtm_indirect_call+0x2c/0x44 [lkdtm] > (target: lkdtm_increment_int+0x0/0x1c [lkdtm]; expected type: 0x7e0c52a) > [ 21.886593] Internal error: Oops - CFI: 0 [#1] PREEMPT SMP > > However, it is not or only partially supported at EL2: in nVHE (or pKVM), > CONFIG_CFI_CLANG gets filtered out at build time, preventing the compiler from > injecting the checks. In VHE (or hVHE), EL2 code gets compiled with the checks Are you sure about hVHE? hVHE is essentially the nVHE object running with a slightly different HCR_EL2 configuration. So if you don't have the checks in the nVHE code, you don't have them for hVHE either. Or am I missing something obvious? Thanks, M.
Hi Marc, On Thu, Mar 14, 2024 at 10:40:47PM +0000, Marc Zyngier wrote: > Hi Pierre-Clément, > > On Thu, 14 Mar 2024 20:23:00 +0000, > Pierre-Clément Tosi <ptosi@google.com> wrote: > > > > CONFIG_CFI_CLANG ("kernel Control Flow Integrity") makes the compiler inject > > runtime type checks before any indirect function call. On AArch64, it generates > > a BRK instruction to be executed on type mismatch and encodes the indices of the > > registers holding the branch target and expected type in the immediate of the > > instruction. As a result, a synchronous exception gets triggered on kCFI failure > > and the fault handler can retrieve the immediate (and indices) from ESR_ELx. > > > > This feature has been supported at EL1 ("host") since it was introduced by > > b26e484b8bb3 ("arm64: Add CFI error handling"), where cfi_handler() decodes > > ESR_EL1, giving informative panic messages such as > > > > [ 21.885179] CFI failure at lkdtm_indirect_call+0x2c/0x44 [lkdtm] > > (target: lkdtm_increment_int+0x0/0x1c [lkdtm]; expected type: 0x7e0c52a) > > [ 21.886593] Internal error: Oops - CFI: 0 [#1] PREEMPT SMP > > > > However, it is not or only partially supported at EL2: in nVHE (or pKVM), > > CONFIG_CFI_CLANG gets filtered out at build time, preventing the compiler from > > injecting the checks. In VHE (or hVHE), EL2 code gets compiled with the checks > > Are you sure about hVHE? hVHE is essentially the nVHE object running > with a slightly different HCR_EL2 configuration. So if you don't have > the checks in the nVHE code, you don't have them for hVHE either. No, I am not and my assumption that hVHE was running the VHE hyp code was wrong. FYI, these patches were tested in VHE, nVHE, and pKVM (with NVHE_EL2_DEBUG set and unset) but not in hVHE (clearly!). Thanks for pointing this out. > > Or am I missing something obvious? > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible.