| Message ID | 1574166746-27197-1-git-send-email-amit.kachhap@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: return address signing | expand |
On Tue, 19 Nov 2019 at 13:33, Amit Daniel Kachhap <amit.kachhap@arm.com> wrote: > > Hi, > > This series improves function return address protection for the arm64 kernel, by > compiling the kernel with ARMv8.3 Pointer Authentication instructions (referred > ptrauth hereafter). This should help protect the kernel against attacks using > return-oriented programming. > > This series is based on v5.4-rc8. > > High-level changes since v1 [1] (detailed changes are listed in patches): > - Dropped patch "arm64: cpufeature: handle conflicts based on capability" > as pointed by Suzuki. > - Patch 4, 10, 12 and 14 are added newly added. > - Patch 12 adds support to block probe of authenticate ptrauth instructions. > - Patch 14 adds support for lkdtm to test ptrauth. > - In the last version if secondary cpus do have ptrauth and primary cpu do not > then the secondary will silently disable ptrauth and keep running. This version > creates panic in this case as suggested by Suzuki. > - Many suggestion from James implemented. > > This series do not implement few things or have known limitations: > - kdump tool may need some rework to work with ptrauth. > - Generate/Get some randomness for ptrauth keys during kernel early booting. > Hello Amit, As we discussed off line, we still need some place to initialize the PAC keys for the boot CPU. We should follow the same approach as boot_init_stack_canary() is currently taking: it is called from start_kernel(), never returns, and it is marked as __always_inline, which means it does not set up a stack frame and so its return address will not get signed with the wrong key. Something like the below should be acceptable for a generic header file, and we can wire up kernel PAC in the arm64 version of the stackprotector.h header whichever way we like.
Hi Ard, On 11/20/19 9:35 PM, Ard Biesheuvel wrote: > On Tue, 19 Nov 2019 at 13:33, Amit Daniel Kachhap <amit.kachhap@arm.com> wrote: >> >> Hi, >> >> This series improves function return address protection for the arm64 kernel, by >> compiling the kernel with ARMv8.3 Pointer Authentication instructions (referred >> ptrauth hereafter). This should help protect the kernel against attacks using >> return-oriented programming. >> >> This series is based on v5.4-rc8. >> >> High-level changes since v1 [1] (detailed changes are listed in patches): >> - Dropped patch "arm64: cpufeature: handle conflicts based on capability" >> as pointed by Suzuki. >> - Patch 4, 10, 12 and 14 are added newly added. >> - Patch 12 adds support to block probe of authenticate ptrauth instructions. >> - Patch 14 adds support for lkdtm to test ptrauth. >> - In the last version if secondary cpus do have ptrauth and primary cpu do not >> then the secondary will silently disable ptrauth and keep running. This version >> creates panic in this case as suggested by Suzuki. >> - Many suggestion from James implemented. >> >> This series do not implement few things or have known limitations: >> - kdump tool may need some rework to work with ptrauth. >> - Generate/Get some randomness for ptrauth keys during kernel early booting. >> > > Hello Amit, > > As we discussed off line, we still need some place to initialize the > PAC keys for the boot CPU. > > We should follow the same approach as boot_init_stack_canary() is > currently taking: it is called from start_kernel(), never returns, and > it is marked as __always_inline, which means it does not set up a > stack frame and so its return address will not get signed with the > wrong key. > > Something like the below should be acceptable for a generic header > file, and we can wire up kernel PAC in the arm64 version of the > stackprotector.h header whichever way we like. > This seems to be a practical approach. I tested in my local system and it works fine. For few functions before boot_init_stack_canary, it can afford to run without keys as randomization driver is not initialised. Thanks for the pointer. Regards, Amit Daniel