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 |
| - `none`: Disable control flow protection. | ||
| - `full`: Protect all control flow instructions, will enable branch protection | ||
| and return protection if the `Zimop` extension is available. | ||
| - `branch`: Protect branch instructions only by insert landing pad. |
| `-fcf-protection` is alias to `-fcf-protection=full`. | ||
|
|
||
| - `none`: Disable control flow protection. | ||
| - `full`: Protect all control flow instructions, will enable branch protection |
There was a problem hiding this comment.
This sentence reads like branch protection requires Zimop, but I think only return protection requires Zimop?
|
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 |
…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...