Messages in this thread | | | From | Sami Tolvanen <> | Date | Mon, 16 May 2022 10:57:15 -0700 | Subject | Re: [RFC PATCH v2 00/21] KCFI support |
| |
On Mon, May 16, 2022 at 10:31 AM Sedat Dilek <sedat.dilek@gmail.com> wrote: >> Anything Like LLVM cmake Options to be condidered and Set? > > > I activate Clang and LLD ad projects - OK - enough?
Clang and LLD should be sufficient.
>> This series is also available in GitHub: >> >> https://github.com/samitolvanen/linux/commits/kcfi-rfc-v2 >> >> >> > >> Can you please add a history of what changed?
Oops, I forgot to include that.
Changes in v2: - Changed the compiler patch to encode arm64 target and type details in the ESR, and updated the kernel error handling patch accordingly. - Changed the compiler patch to embed the x86_64 type hash in a valid instruction to avoid special casing objtool instruction decoding, and added a __cfi_ symbol for the preamble. Changed the kernel error handling and manual type annotations to match. - Dropped the .kcfi_types section as that’s no longer needed by objtool, and changed the objtool patch to simply ignore the __cfi_ preambles falling through. - Dropped the .kcfi_traps section on arm64 as it’s no longer needed, and moved the trap look-up code behind CONFIG_ARCH_USES_CFI_TRAPS, which is selected only for x86_64. - Dropped __nocfi attributes from arm64 code where CFI was disabled due to address space confusion issues, and added type annotations to relevant assembly functions. - Dropped __nocfi from __init.
> Nathan has a i915 cfi patch in His personal kernel.org Git. > Is this relevant to kcfi?
It fixes a type mismatch, so in that sense it's relevant.
> To distinguish between clang-cfi we should use different kbuild variables for kcfi.
The plan is to replace the current CFI implementation. Does reusing the kbuild variable names cause a problem?
Sami
| |