diff mbox series

[v4,1/4] x86/livepatch: align functions to ensure minimal distance between entry points

Message ID 20231215111842.8009-2-roger.pau@citrix.com (mailing list archive)
State New, archived
Headers show
Series xen/x86: add testing for self modifying code and livepatch | expand

Commit Message

Roger Pau Monné Dec. 15, 2023, 11:18 a.m. UTC
The minimal function size requirements for livepatch are either 5 bytes (for
jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm.  Ensure
that distance between functions entry points is always at least of the minimal
required size for livepatch instruction replacement to be successful.

Add an additional align directive to the linker script, in order to ensure that
the next section placed after the .text.* (per-function sections) is also
aligned to the required boundary, so that the distance of the last function
entry point with the next symbol is also of minimal size.

Note that it's possible for the compiler to end up using a higher function
alignment regardless of the passed value, so this change just make sure that
the minimum required for livepatch to work is present.  Different compilers
handle the option differently, as clang will ignore -falign-functions value
if it's smaller than the one that would be set by the optimization level, while
gcc seems to always honor the function alignment passed in -falign-functions.
In order to cope with this behavior and avoid that setting -falign-functions
results in an alignment inferior to what the optimization level would have
selected force x86 release builds to use a function alignment of 16 bytes.

The compiler option -falign-functions is not available on at least clang 3.8,
so introduce a Kconfig check for it and make the livepatch option depend on the
compiler supporting the option.

The naming of the option(s) CONFIG_FUNCTION_ALIGNMENT is explicitly not
mentioning CC in preparation for the option also being used by assembly code.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v3:
 - Test for compiler option with -falign-functions.
 - Make FUNCTION_ALIGNMENT depend on CC_HAS_FUNCTION_ALIGNMENT.
 - Set 16byte function alignment for x86 release builds.

Changes since v2:
 - Add Arm side.
 - Align end of section in the linker script to ensure enough padding for the
   last function.
 - Expand commit message and subject.
 - Rework Kconfig options.
 - Check that the compiler supports the option.

Changes since v1:
 - New in this version.
---
 xen/Kconfig              | 19 +++++++++++++++++++
 xen/Makefile             |  3 +++
 xen/arch/arm/livepatch.c |  2 ++
 xen/arch/arm/xen.lds.S   |  4 ++++
 xen/arch/x86/Kconfig     |  1 +
 xen/arch/x86/livepatch.c |  4 ++++
 xen/arch/x86/xen.lds.S   |  4 ++++
 xen/common/Kconfig       |  5 ++++-
 8 files changed, 41 insertions(+), 1 deletion(-)

Comments

Jan Beulich Dec. 19, 2023, 4:31 p.m. UTC | #1
On 15.12.2023 12:18, Roger Pau Monne wrote:
> The minimal function size requirements for livepatch are either 5 bytes (for
> jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm.  Ensure
> that distance between functions entry points is always at least of the minimal
> required size for livepatch instruction replacement to be successful.
> 
> Add an additional align directive to the linker script, in order to ensure that
> the next section placed after the .text.* (per-function sections) is also
> aligned to the required boundary, so that the distance of the last function
> entry point with the next symbol is also of minimal size.
> 
> Note that it's possible for the compiler to end up using a higher function
> alignment regardless of the passed value, so this change just make sure that
> the minimum required for livepatch to work is present.  Different compilers
> handle the option differently, as clang will ignore -falign-functions value
> if it's smaller than the one that would be set by the optimization level, while
> gcc seems to always honor the function alignment passed in -falign-functions.
> In order to cope with this behavior and avoid that setting -falign-functions
> results in an alignment inferior to what the optimization level would have
> selected force x86 release builds to use a function alignment of 16 bytes.
> 
> The compiler option -falign-functions is not available on at least clang 3.8,
> so introduce a Kconfig check for it and make the livepatch option depend on the
> compiler supporting the option.
> 
> The naming of the option(s) CONFIG_FUNCTION_ALIGNMENT is explicitly not
> mentioning CC in preparation for the option also being used by assembly code.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper Dec. 19, 2023, 7:46 p.m. UTC | #2
On 15/12/2023 11:18 am, Roger Pau Monne wrote:
> The minimal function size requirements for livepatch are either 5 bytes (for

"for an x86 livepatch", seeing as we're touching multiple architectures
worth of files.

I know it's at the end of the sentence, but it wants to be earlier to be
clearer.

> jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm.  Ensure
> that distance between functions entry points is always at least of the minimal
> required size for livepatch instruction replacement to be successful.
>
> Add an additional align directive to the linker script, in order to ensure that
> the next section placed after the .text.* (per-function sections) is also
> aligned to the required boundary, so that the distance of the last function
> entry point with the next symbol is also of minimal size.
>
> Note that it's possible for the compiler to end up using a higher function
> alignment regardless of the passed value, so this change just make sure that
> the minimum required for livepatch to work is present.  Different compilers
> handle the option differently, as clang will ignore -falign-functions value
> if it's smaller than the one that would be set by the optimization level, while
> gcc seems to always honor the function alignment passed in -falign-functions.
> In order to cope with this behavior and avoid that setting -falign-functions
> results in an alignment inferior to what the optimization level would have
> selected force x86 release builds to use a function alignment of 16 bytes.

Yuck :(

The same will be true for all other architectures too?

What happens on ARM, which also picks up an explicit choice in livepatch
builds?

>
> The compiler option -falign-functions is not available on at least clang 3.8,
> so introduce a Kconfig check for it and make the livepatch option depend on the
> compiler supporting the option.
>
> The naming of the option(s) CONFIG_FUNCTION_ALIGNMENT is explicitly not
> mentioning CC in preparation for the option also being used by assembly code.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Changes since v3:
>  - Test for compiler option with -falign-functions.
>  - Make FUNCTION_ALIGNMENT depend on CC_HAS_FUNCTION_ALIGNMENT.
>  - Set 16byte function alignment for x86 release builds.
>
> Changes since v2:
>  - Add Arm side.
>  - Align end of section in the linker script to ensure enough padding for the
>    last function.
>  - Expand commit message and subject.
>  - Rework Kconfig options.
>  - Check that the compiler supports the option.
>
> Changes since v1:
>  - New in this version.
> ---
>  xen/Kconfig              | 19 +++++++++++++++++++
>  xen/Makefile             |  3 +++
>  xen/arch/arm/livepatch.c |  2 ++
>  xen/arch/arm/xen.lds.S   |  4 ++++
>  xen/arch/x86/Kconfig     |  1 +
>  xen/arch/x86/livepatch.c |  4 ++++
>  xen/arch/x86/xen.lds.S   |  4 ++++
>  xen/common/Kconfig       |  5 ++++-
>  8 files changed, 41 insertions(+), 1 deletion(-)

xen$ git ls-files | grep xen.lds.S
arch/arm/xen.lds.S
arch/ppc/xen.lds.S
arch/riscv/xen.lds.S
arch/x86/xen.lds.S

RISC-V and PPC have the same pattern that you're patching for x86 and ARM.


> diff --git a/xen/Kconfig b/xen/Kconfig
> index 134e6e68ad84..c2cc3fe165eb 100644
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -37,6 +37,25 @@ config CC_HAS_VISIBILITY_ATTRIBUTE
>  config CC_SPLIT_SECTIONS
>  	bool
>  
> +# Set function alignment.
> +#
> +# Allow setting on a boolean basis, and then convert such selection to an
> +# integer for the build system and code to consume more easily.

# Clang >= 6.0

> +config CC_HAS_FUNCTION_ALIGNMENT
> +	def_bool $(cc-option,-falign-functions)
> +config FUNCTION_ALIGNMENT_4B
> +	bool
> +config FUNCTION_ALIGNMENT_8B
> +	bool
> +config FUNCTION_ALIGNMENT_16B
> +	bool
> +config FUNCTION_ALIGNMENT
> +	int
> +	depends on CC_HAS_FUNCTION_ALIGNMENT
> +	default 16 if FUNCTION_ALIGNMENT_16B
> +	default  8 if  FUNCTION_ALIGNMENT_8B
> +	default  4 if  FUNCTION_ALIGNMENT_4B

What value do we get here for RISCV/PPC?  Do we need another override
for them?

~Andrew
Roger Pau Monné Dec. 20, 2023, 8:32 a.m. UTC | #3
On Tue, Dec 19, 2023 at 07:46:11PM +0000, Andrew Cooper wrote:
> On 15/12/2023 11:18 am, Roger Pau Monne wrote:
> > The minimal function size requirements for livepatch are either 5 bytes (for
> 
> "for an x86 livepatch", seeing as we're touching multiple architectures
> worth of files.
> 
> I know it's at the end of the sentence, but it wants to be earlier to be
> clearer.
> 
> > jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm.  Ensure
> > that distance between functions entry points is always at least of the minimal
> > required size for livepatch instruction replacement to be successful.
> >
> > Add an additional align directive to the linker script, in order to ensure that
> > the next section placed after the .text.* (per-function sections) is also
> > aligned to the required boundary, so that the distance of the last function
> > entry point with the next symbol is also of minimal size.
> >
> > Note that it's possible for the compiler to end up using a higher function
> > alignment regardless of the passed value, so this change just make sure that
> > the minimum required for livepatch to work is present.  Different compilers
> > handle the option differently, as clang will ignore -falign-functions value
> > if it's smaller than the one that would be set by the optimization level, while
> > gcc seems to always honor the function alignment passed in -falign-functions.
> > In order to cope with this behavior and avoid that setting -falign-functions
> > results in an alignment inferior to what the optimization level would have
> > selected force x86 release builds to use a function alignment of 16 bytes.
> 
> Yuck :(
> 
> The same will be true for all other architectures too?

I would expect that for gcc I guess.

> What happens on ARM, which also picks up an explicit choice in livepatch
> builds?

Arm AFAICT seems to use a 4 byte function alignment with -O2 (both gcc
and clang), so that matches what we need to enforce for livepatch.  If
we ever need a higher alignment for livepatch reasons it would be a
multiple of the minimum one set by the compiler, so that should be
fine.

> >
> > The compiler option -falign-functions is not available on at least clang 3.8,
> > so introduce a Kconfig check for it and make the livepatch option depend on the
> > compiler supporting the option.
> >
> > The naming of the option(s) CONFIG_FUNCTION_ALIGNMENT is explicitly not
> > mentioning CC in preparation for the option also being used by assembly code.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Changes since v3:
> >  - Test for compiler option with -falign-functions.
> >  - Make FUNCTION_ALIGNMENT depend on CC_HAS_FUNCTION_ALIGNMENT.
> >  - Set 16byte function alignment for x86 release builds.
> >
> > Changes since v2:
> >  - Add Arm side.
> >  - Align end of section in the linker script to ensure enough padding for the
> >    last function.
> >  - Expand commit message and subject.
> >  - Rework Kconfig options.
> >  - Check that the compiler supports the option.
> >
> > Changes since v1:
> >  - New in this version.
> > ---
> >  xen/Kconfig              | 19 +++++++++++++++++++
> >  xen/Makefile             |  3 +++
> >  xen/arch/arm/livepatch.c |  2 ++
> >  xen/arch/arm/xen.lds.S   |  4 ++++
> >  xen/arch/x86/Kconfig     |  1 +
> >  xen/arch/x86/livepatch.c |  4 ++++
> >  xen/arch/x86/xen.lds.S   |  4 ++++
> >  xen/common/Kconfig       |  5 ++++-
> >  8 files changed, 41 insertions(+), 1 deletion(-)
> 
> xen$ git ls-files | grep xen.lds.S
> arch/arm/xen.lds.S
> arch/ppc/xen.lds.S
> arch/riscv/xen.lds.S
> arch/x86/xen.lds.S
> 
> RISC-V and PPC have the same pattern that you're patching for x86 and ARM.

I've avoided touching those because there's no livepatch support there
(yet), and I didn't want to give the impression that the option is
supported or tested for those architectures.  I have no idea what
function alignments would be sensible for riscv or ppc.

> > diff --git a/xen/Kconfig b/xen/Kconfig
> > index 134e6e68ad84..c2cc3fe165eb 100644
> > --- a/xen/Kconfig
> > +++ b/xen/Kconfig
> > @@ -37,6 +37,25 @@ config CC_HAS_VISIBILITY_ATTRIBUTE
> >  config CC_SPLIT_SECTIONS
> >  	bool
> >  
> > +# Set function alignment.
> > +#
> > +# Allow setting on a boolean basis, and then convert such selection to an
> > +# integer for the build system and code to consume more easily.
> 
> # Clang >= 6.0
> 
> > +config CC_HAS_FUNCTION_ALIGNMENT
> > +	def_bool $(cc-option,-falign-functions)
> > +config FUNCTION_ALIGNMENT_4B
> > +	bool
> > +config FUNCTION_ALIGNMENT_8B
> > +	bool
> > +config FUNCTION_ALIGNMENT_16B
> > +	bool
> > +config FUNCTION_ALIGNMENT
> > +	int
> > +	depends on CC_HAS_FUNCTION_ALIGNMENT
> > +	default 16 if FUNCTION_ALIGNMENT_16B
> > +	default  8 if  FUNCTION_ALIGNMENT_8B
> > +	default  4 if  FUNCTION_ALIGNMENT_4B
> 
> What value do we get here for RISCV/PPC?  Do we need another override
> for them?

Hm, I wasn't planning on adding support for PPC/RISCV here, if those
arches want to use a specific function alignment they might need to
adjust the options here, I think that's a reasonable compromise, as I
don't see a need for this to be blocked on also agreeing values for
ppc or riscv.

Thanks, Roger.
Jan Beulich Dec. 20, 2023, 9:03 a.m. UTC | #4
On 20.12.2023 09:32, Roger Pau Monné wrote:
> On Tue, Dec 19, 2023 at 07:46:11PM +0000, Andrew Cooper wrote:
>> On 15/12/2023 11:18 am, Roger Pau Monne wrote:
>>> The minimal function size requirements for livepatch are either 5 bytes (for
>>
>> "for an x86 livepatch", seeing as we're touching multiple architectures
>> worth of files.
>>
>> I know it's at the end of the sentence, but it wants to be earlier to be
>> clearer.
>>
>>> jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm.  Ensure
>>> that distance between functions entry points is always at least of the minimal
>>> required size for livepatch instruction replacement to be successful.
>>>
>>> Add an additional align directive to the linker script, in order to ensure that
>>> the next section placed after the .text.* (per-function sections) is also
>>> aligned to the required boundary, so that the distance of the last function
>>> entry point with the next symbol is also of minimal size.
>>>
>>> Note that it's possible for the compiler to end up using a higher function
>>> alignment regardless of the passed value, so this change just make sure that
>>> the minimum required for livepatch to work is present.  Different compilers
>>> handle the option differently, as clang will ignore -falign-functions value
>>> if it's smaller than the one that would be set by the optimization level, while
>>> gcc seems to always honor the function alignment passed in -falign-functions.
>>> In order to cope with this behavior and avoid that setting -falign-functions
>>> results in an alignment inferior to what the optimization level would have
>>> selected force x86 release builds to use a function alignment of 16 bytes.
>>
>> Yuck :(
>>
>> The same will be true for all other architectures too?
> 
> I would expect that for gcc I guess.
> 
>> What happens on ARM, which also picks up an explicit choice in livepatch
>> builds?
> 
> Arm AFAICT seems to use a 4 byte function alignment with -O2 (both gcc
> and clang), so that matches what we need to enforce for livepatch.  If
> we ever need a higher alignment for livepatch reasons it would be a
> multiple of the minimum one set by the compiler, so that should be
> fine.

Thinking of it: The forcing of 16-byte alignment in release builds of x86
is based on observations with certain compiler versions, iirc. What if
future versions decide to go lower/higher for, perhaps, very good reasons?
We don't really mean to override the compiler's choice, so maybe further
probing is actually necessary?

Jan
Roger Pau Monné Dec. 20, 2023, 9:19 a.m. UTC | #5
On Wed, Dec 20, 2023 at 10:03:51AM +0100, Jan Beulich wrote:
> On 20.12.2023 09:32, Roger Pau Monné wrote:
> > On Tue, Dec 19, 2023 at 07:46:11PM +0000, Andrew Cooper wrote:
> >> On 15/12/2023 11:18 am, Roger Pau Monne wrote:
> >>> The minimal function size requirements for livepatch are either 5 bytes (for
> >>
> >> "for an x86 livepatch", seeing as we're touching multiple architectures
> >> worth of files.
> >>
> >> I know it's at the end of the sentence, but it wants to be earlier to be
> >> clearer.
> >>
> >>> jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm.  Ensure
> >>> that distance between functions entry points is always at least of the minimal
> >>> required size for livepatch instruction replacement to be successful.
> >>>
> >>> Add an additional align directive to the linker script, in order to ensure that
> >>> the next section placed after the .text.* (per-function sections) is also
> >>> aligned to the required boundary, so that the distance of the last function
> >>> entry point with the next symbol is also of minimal size.
> >>>
> >>> Note that it's possible for the compiler to end up using a higher function
> >>> alignment regardless of the passed value, so this change just make sure that
> >>> the minimum required for livepatch to work is present.  Different compilers
> >>> handle the option differently, as clang will ignore -falign-functions value
> >>> if it's smaller than the one that would be set by the optimization level, while
> >>> gcc seems to always honor the function alignment passed in -falign-functions.
> >>> In order to cope with this behavior and avoid that setting -falign-functions
> >>> results in an alignment inferior to what the optimization level would have
> >>> selected force x86 release builds to use a function alignment of 16 bytes.
> >>
> >> Yuck :(
> >>
> >> The same will be true for all other architectures too?
> > 
> > I would expect that for gcc I guess.
> > 
> >> What happens on ARM, which also picks up an explicit choice in livepatch
> >> builds?
> > 
> > Arm AFAICT seems to use a 4 byte function alignment with -O2 (both gcc
> > and clang), so that matches what we need to enforce for livepatch.  If
> > we ever need a higher alignment for livepatch reasons it would be a
> > multiple of the minimum one set by the compiler, so that should be
> > fine.
> 
> Thinking of it: The forcing of 16-byte alignment in release builds of x86
> is based on observations with certain compiler versions, iirc. What if
> future versions decide to go lower/higher for, perhaps, very good reasons?
> We don't really mean to override the compiler's choice, so maybe further
> probing is actually necessary?

We do override the default (on gcc) when using livepatch anyway, so we
might as well be consistent and attempt to provide a value that's
reasonable?

Linux currently uses 16-byte also on x86 and set in Kconfig, and all
compiler versions I've tested use 16-bytes with -O2, so I think it's
unlikely to change overnight (and a lot of software will still use 16
anyway).

If a more suitable value is needed in the future we can always adjust,
that's the whole point of having it in Kconfig.  We can also select a
better value even in compilers that might not know about it.

Thanks, Roger.
diff mbox series

Patch

diff --git a/xen/Kconfig b/xen/Kconfig
index 134e6e68ad84..c2cc3fe165eb 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -37,6 +37,25 @@  config CC_HAS_VISIBILITY_ATTRIBUTE
 config CC_SPLIT_SECTIONS
 	bool
 
+# Set function alignment.
+#
+# Allow setting on a boolean basis, and then convert such selection to an
+# integer for the build system and code to consume more easily.
+config CC_HAS_FUNCTION_ALIGNMENT
+	def_bool $(cc-option,-falign-functions)
+config FUNCTION_ALIGNMENT_4B
+	bool
+config FUNCTION_ALIGNMENT_8B
+	bool
+config FUNCTION_ALIGNMENT_16B
+	bool
+config FUNCTION_ALIGNMENT
+	int
+	depends on CC_HAS_FUNCTION_ALIGNMENT
+	default 16 if FUNCTION_ALIGNMENT_16B
+	default  8 if  FUNCTION_ALIGNMENT_8B
+	default  4 if  FUNCTION_ALIGNMENT_4B
+
 source "arch/$(SRCARCH)/Kconfig"
 
 config DEFCONFIG_LIST
diff --git a/xen/Makefile b/xen/Makefile
index 21832d640225..162cb2bda1c5 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -390,6 +390,9 @@  CFLAGS += -fomit-frame-pointer
 endif
 
 CFLAGS-$(CONFIG_CC_SPLIT_SECTIONS) += -ffunction-sections -fdata-sections
+ifdef CONFIG_FUNCTION_ALIGNMENT
+CFLAGS += -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT)
+endif
 
 CFLAGS += -nostdinc -fno-builtin -fno-common
 CFLAGS += -Werror -Wredundant-decls -Wwrite-strings -Wno-pointer-arith
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index bbca1e5a5ed3..aa8ae8c38d28 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -68,6 +68,8 @@  void arch_livepatch_revive(void)
 
 int arch_livepatch_verify_func(const struct livepatch_func *func)
 {
+    BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE > CONFIG_FUNCTION_ALIGNMENT);
+
     /* If NOPing only do up to maximum amount we can put in the ->opaque. */
     if ( !func->new_addr && (func->new_size > LIVEPATCH_OPAQUE_SIZE ||
          func->new_size % ARCH_PATCH_INSN_SIZE) )
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 59b80d122fd0..afaf1e996b0e 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -44,6 +44,10 @@  SECTIONS
 #ifdef CONFIG_CC_SPLIT_SECTIONS
        *(.text.*)
 #endif
+#ifdef CONFIG_FUNCTION_ALIGNMENT
+       /* Ensure enough distance with the next placed section. */
+       . = ALIGN(CONFIG_FUNCTION_ALIGNMENT);
+#endif
 
        *(.fixup)
        *(.gnu.warning)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 1acdffc51c22..0cd741be5b6f 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -29,6 +29,7 @@  config X86
 	select HAS_UBSAN
 	select HAS_VPCI if HVM
 	select NEEDS_LIBELF
+	select FUNCTION_ALIGNMENT_16B if !DEBUG
 
 config ARCH_DEFCONFIG
 	string
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index ee539f001b73..b00ad7120da9 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -109,6 +109,10 @@  int arch_livepatch_verify_func(const struct livepatch_func *func)
          */
         uint8_t needed = ARCH_PATCH_INSN_SIZE;
 
+        BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE +
+                     (IS_ENABLED(CONIFG_XEN_IBT) ? ENDBR64_LEN : 0) >
+                     CONFIG_FUNCTION_ALIGNMENT);
+
         if ( is_endbr64(func->old_addr) || is_endbr64_poison(func->old_addr) )
             needed += ENDBR64_LEN;
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 8930e14fc40e..5b3332300d44 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -99,6 +99,10 @@  SECTIONS
        *(.text)
 #ifdef CONFIG_CC_SPLIT_SECTIONS
        *(.text.*)
+#endif
+#ifdef CONFIG_FUNCTION_ALIGNMENT
+       /* Ensure enough distance with the next placed section. */
+       . = ALIGN(CONFIG_FUNCTION_ALIGNMENT);
 #endif
        *(.text.__x86_indirect_thunk_*)
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 310ad4229cdf..c9a21c3c8a07 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -395,8 +395,11 @@  config CRYPTO
 config LIVEPATCH
 	bool "Live patching support"
 	default X86
-	depends on "$(XEN_HAS_BUILD_ID)" = "y"
+	depends on "$(XEN_HAS_BUILD_ID)" = "y" && CC_HAS_FUNCTION_ALIGNMENT
 	select CC_SPLIT_SECTIONS
+	select FUNCTION_ALIGNMENT_16B if XEN_IBT
+	select FUNCTION_ALIGNMENT_8B  if X86
+	select FUNCTION_ALIGNMENT_4B
 	---help---
 	  Allows a running Xen hypervisor to be dynamically patched using
 	  binary patches without rebooting. This is primarily used to binarily