On 28/11/2023 10:03 am, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index f3abdf9cd111..f629157086d0 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -82,6 +82,8 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
> obj-y += sysctl.o
> endif
>
> +CFLAGS-$(CONFIG_LIVEPATCH) +=
> -falign-functions=$(CONFIG_CC_FUNCTION_ALIGNMENT)
I'd really prefer not to express it like this. For one, a major reason
for using an alignment of 16b or more is simply performance.
Also, it isn't "CC" when we get the asm macros working.
Copy Linux more closely. Then, you have LIVEPATCH select
FUNCTION_ALIGNMENT_{8,16}B as appropriate. And PERFORMANCE selects
FUNCTION_ALIGNMENT_16B or perhaps 32B depending on uarch.
If we ever get around to having KCFI, then we need 16B irrespective of
anything else.
As for the subject, it's not really about size; the function size is
still going to be small irrespective of the alignment. It's about
having space in the final binary to livepatch:
int foo(void)
{
return 0;
}
into
int foo(void)
{
return 1;
}
which is something you can't always do right now without overwriting the
head of whichever function is following foo() in the binary.
~Andrew
