riscv kernel control flow integrity
| From: | Deepak Gupta <debug-AT-rivosinc.com> | |
| To: | linux-riscv-AT-lists.infradead.org, linux-kernel-AT-vger.kernel.org, llvm-AT-lists.linux.dev | |
| Subject: | [RFC PATCH v1] riscv kernel control flow integrity | |
| Date: | Mon, 08 Apr 2024 23:10:31 -0700 | |
| Message-ID: | <20240409061043.3269676-1-debug@rivosinc.com> | |
| Cc: | paul.walmsley-AT-sifive.com, palmer-AT-dabbelt.com, aou-AT-eecs.berkeley.edu, nathan-AT-kernel.org, ndesaulniers-AT-google.com, morbo-AT-google.com, justinstitt-AT-google.com, andy.chiu-AT-sifive.com, debug-AT-rivosinc.com, hankuan.chen-AT-sifive.com, guoren-AT-kernel.org, greentime.hu-AT-sifive.com, samitolvanen-AT-google.com, cleger-AT-rivosinc.com, apatel-AT-ventanamicro.com, ajones-AT-ventanamicro.com, conor.dooley-AT-microchip.com, mchitale-AT-ventanamicro.com, dbarboza-AT-ventanamicro.com, waylingii-AT-gmail.com, sameo-AT-rivosinc.com, alexghiti-AT-rivosinc.com, akpm-AT-linux-foundation.org, shikemeng-AT-huaweicloud.com, rppt-AT-kernel.org, charlie-AT-rivosinc.com, xiao.w.wang-AT-intel.com, willy-AT-infradead.org, jszhang-AT-kernel.org, leobras-AT-redhat.com, songshuaishuai-AT-tinylab.org, haxel-AT-fzi.de, samuel.holland-AT-sifive.com, namcaov-AT-gmail.com, bjorn-AT-rivosinc.com, cuiyunhui-AT-bytedance.com, wangkefeng.wang-AT-huawei.com, falcon-AT-tinylab.org, viro-AT-zeniv.linux.org.uk, bhe-AT-redhat.com, chenjiahao16-AT-huawei.com, hca-AT-linux.ibm.com, arnd-AT-arndb.de, kent.overstreet-AT-linux.dev, boqun.feng-AT-gmail.com, oleg-AT-redhat.com, paulmck-AT-kernel.org, broonie-AT-kernel.org, rick.p.edgecombe-AT-intel.com | |
| Archive-link: | Article |
Basic overview --------------- This is a RFC patch series for enabling kernel control flow integrity on riscv architecture. This patch series enables kernel control flow integrity using proposed riscv cpu extensions `zicfilp` and `zicfiss` [1]. `zicfilp` enforces that all indirect calls and jumps must land on a landing pad instruction (`lpad`). Additionally `lpad` has 20bit encoded value as part of instruction and cpu will check this 20bit value with t2/x7 register , if they mismatch then cpu will raise an exception `software check exception` (a new exception with cause=18). In this patch series, a constant label value of 0x1 is used. As series will mature, it will switch to a 20 bit truncated hash over function signature. Label based on function signature allows stricter control flow and fewer call/jmp locations from a callsite. `zicfiss` protects the return path from functions where return relies on obtaining return address from stack which is corruptible. `zicfiss` provides a shadow stack which can be used by software to place return addresses on shadow stack and while returning from function it can be used to compare against return address from regular stack. If they dont match, cpu will raise software check exception. `zicfiss` based shadow stack are protected against tampering using special page table encodings (please refer to [1]) To obtain more details about `zicfiss` and `zicfilp` ISA extension, please refer to [1]. There is an ongoing patchsets for enabling this feature for user mode software here [2] Enabling on kernel =================== This patch series introduces new riscv config `CONFIG_RISCV_KERNEL_CFI`. If this config is selected, it turns on - forward control flow for kernel using `zicfilp` - selects `CONFIG_SHADOW_CALL_STACK` /w `CONFIG_DYNAMIC_SCS` to enable backward control flow. forward control flow for kernel ================================ This patch series simply compiles kernel with `march=_zicfilp` compiler option. Currently toolchain uses constant label scheme of label = 0x1. This patch series manually fixes some of the assembly callsites and sequences to make sure they are not breaking rules setup by `zicfilp`. backward control flow for kernel ================================= There is an existing support for riscv kernel for shadow call stack [3], which is a software based shadow stack and uses clang /w instrumentation to push/pop return address in prolog and epilog of functions. Although software based shadow stack lacks memory protections and thus suffers from same issue of return address susceptible to hijacking. shadow call stack uses `CONFIG_SHADOW_CALL_STACK` /w option of `CONFIG_DYNAMIC_SCS` so that hardware vendors hook into the flow to provide stronger guarantees. This patch uses `CONFIG_SHADOW_CALL_STACK` flow along with `CONFIG_DYNAMIC_SCS` to enable return control flow integrity on riscv kernel. [1] - https://github.com/riscv/riscv-cfi [2] - https://lore.kernel.org/all/20240403234054.2020347-1-debu... [3] - https://lore.kernel.org/all/20230927224757.1154247-8-sami...
