[PATCH v4 1/4] x86/ibt: factor out cfi and fineibt offset
Peter Zijlstra
peterz at infradead.org
Mon Mar 3 08:54:54 PST 2025
On Mon, Mar 03, 2025 at 09:28:34PM +0800, Menglong Dong wrote:
> For now, the layout of cfi and fineibt is hard coded, and the padding is
> fixed on 16 bytes.
>
> Factor out FINEIBT_INSN_OFFSET and CFI_INSN_OFFSET. CFI_INSN_OFFSET is
> the offset of cfi, which is the same as FUNCTION_ALIGNMENT when
> CALL_PADDING is enabled. And FINEIBT_INSN_OFFSET is the offset where we
> put the fineibt preamble on, which is 16 for now.
>
> When the FUNCTION_ALIGNMENT is bigger than 16, we place the fineibt
> preamble on the last 16 bytes of the padding for better performance, which
> means the fineibt preamble don't use the space that cfi uses.
>
> The FINEIBT_INSN_OFFSET is not used in fineibt_caller_start and
> fineibt_paranoid_start, as it is always "0x10". Note that we need to
> update the offset in fineibt_caller_start and fineibt_paranoid_start if
> FINEIBT_INSN_OFFSET changes.
>
> Signed-off-by: Menglong Dong <dongml2 at chinatelecom.cn>
I'm confused as to what exactly you mean.
Preamble will have __cfi symbol and some number of NOPs right before
actual symbol like:
__cfi_foo:
mov $0x12345678, %reg
nop
nop
nop
...
foo:
FineIBT must be at foo-16, has nothing to do with performance. This 16
can also be spelled: fineibt_preamble_size.
The total size of the preamble is FUNCTION_PADDING_BYTES + CFI_CLANG*5.
If you increase FUNCTION_PADDING_BYTES by another 5, which is what you
want I think, then we'll have total preamble of 21 bytes; 5 bytes kCFI,
16 bytes nop.
Then kCFI expects hash to be at -20, while FineIBT must be at -16.
This then means there is no unambiguous hole for you to stick your
meta-data thing (whatever that is).
There are two options: make meta data location depend on cfi_mode, or
have __apply_fineibt() rewrite kCFI to also be at -16, so that you can
have -21 for your 5 bytes.
I think I prefer latter.
In any case, I don't think we need *_INSN_OFFSET. At most we need
PREAMBLE_SIZE.
Hmm?
More information about the linux-arm-kernel
mailing list