Add options for enable code gen with CFI `-fcf-protection=[full|branc… #54
Conversation
|
I believe all mentions of the |
Oh, yeah, apparently I lost my memory when I wrote this PR |
kito-cheng
force-pushed
the
kitoc/cfi-option
branch
from
ce3e2dd to
9f98db4
Compare
…h|return|none]` and `-mcf-label-scheme=[unlabeled|func-sig]` Resue the options defined by X86 CET, `-fcf-protection=[full|branch|return|none]` `-fcf-protection=branch` for landing pad (`Zicfilp`), `-fcf-protection=return` for landing pad (`Zicfiss`) and `-fcf-protection=full` for enable both if possible, landing pad just require instrcution defined by base extension, so compiler will emit landing pad even without `Zicfilp` extension, but `-fcf-protection=return` will require at least `Zimop` since the instrcution isn't included in base extension. Also we defined another option for specify the labeling scheme: `unlabeled` and `func-sig`. The `unlabeled` scheme is always use `lpad 0`, and `func-sig` is based on the function signature, the rule is defined in psABI.
kito-cheng
force-pushed
the
kitoc/cfi-option
branch
from
9f98db4 to
5c64887
Compare
|
Changes:
|
|
Do we have conclusion on which option to implement now? |
I'm good with Besides the adoption of this |
|
Hi @kito-cheng, To clarify our last discussion during the RISCV sync-up, does |
|
At LLVM sync up meeting, we would like use |
|
Thank you, @kito-cheng, for your response. I have one more clarification: when referring to |
|
@quic-garvgupt oh, that's my stupid typo (and copy/paste), should be |
|
Both GCC[1] and LLVM[2] has landed, so I believe this PR is ready to land :) @cmuellner could you help me to merge this? |
…109600) This patch adds preprocessor macros when Zicfilp CFI is enabled. To be specific: + `#define __riscv_landing_pad 1` when `-fcf-protection=[full|branch]` + `#define __riscv_landing_pad_unlabeled 1` when `-fcf-protection=[full|branch] -mcf-branch-label-scheme=unlabeled` The macros are proposed in riscv-non-isa/riscv-c-api-doc#76 , and the CLI flags are from riscv-non-isa/riscv-toolchain-conventions#54.
…or macros (#109600) This patch adds preprocessor macros when Zicfilp CFI is enabled. To be specific: + `#define __riscv_landing_pad 1` when `-fcf-protection=[full|branch]` + `#define __riscv_landing_pad_unlabeled 1` when `-fcf-protection=[full|branch] -mcf-branch-label-scheme=unlabeled` The macros are proposed in riscv-non-isa/riscv-c-api-doc#76 , and the CLI flags are from riscv-non-isa/riscv-toolchain-conventions#54.
…h|return|none]
and-mcf-label-scheme=[unlabeled|func-sig]`Resue the options defined by X86 CET,
-fcf-protection=[full|branch|return|none]-fcf-protection=branchfor landing pad (Zicfilp),-fcf-protection=returnfor landing pad (Zicfiss) and-fcf-protection=fullfor enable both if possible, landing pad just require instrcution defined by base extension, so compiler will emit landing pad even withoutZicfilpextension, but-fcf-protection=returnwill require at leastZimopsince the instrcution isn't included in base extension.Also we defined another option for specify the labeling scheme:
unlabeledandfunc-sig.The
unlabeledscheme is always uselpad 0, andfunc-sigis based on the function signature, the rule is defined in psABI.Currently clang/LLVM using
-fsanitize=shadow-call-stackto control the shadow stack, also that shared same option with software shadow shadow, so I think we have three options for this:-fsanitize=shadow-call-stackalias to-fcf-protection=return-fsanitize=shadow-call-stackonly for software shadow stack-fcf-protection=returnand only-fsanitize=shadow-call-stackI am OK with option 1 or 2 and prefer option 2, and dislike option 3 since it means we have very different flavor option naming scheme on landing pad and shadows stack...