On Sun, Dec 18, 2022 at 10:17:58PM -0800, Dan Li wrote: > In the compiler part[4], there are some differences from Sami's > implementation[3], mainly including: > > 1. When a typeid mismatch is detected, the cfi_check_failed function > will be called instead of the brk instruction. This function needs > to be implemented by the compiler user. > If there are user mode programs or other systems that want to use > this feature, it may be more convenient to use a callback (so this > compilation option is set to -fsanitize=cfi instead of kcfi). This is not going to be acceptible for x86_64. > 2. A reserved typeid (such as 0x0U on the aarch64 platform) is always > inserted in front of functions that should not be called indirectly. > Functions that can be called indirectly will not use this hash value, > which prevents instructions/data before the function from being used > as a typeid by an attacker. > > 3. Some bits are ignored in the typeid to avoid conflicts between the > typeid and the instruction set of a specific platform, thereby > preventing an attacker from bypassing the CFI check by using the > instruction as a typeid, such as on the aarch64 platform: > * If the following instruction sequence exists: > 400620: a9be7bfd stp x29, x30, [sp, #-32]! > 400624: 910003fd mov x29, sp > 400628: f9000bf3 str x19, [sp, #16] > * If the expected typeid of the indirect call is exactly 0x910003fd, > the attacker can jump to the next instruction position of any > "mov x29,sp" instruction (such as 0x400628 here). > > 4. Insert a symbol __cfi_<function> before each function's typeid, > which may be helpful for fine-grained KASLR implementations (or not?). > > 5. The current implementation of gcc only supports the aarch64 platform. What, if any, are the plans for x86_64 support?
