Re: [PATCH v9] common: honor CONFIG_CC_SPLIT_SECTIONS also for assembly functions

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Fri Feb 13, 2026 at 9:12 AM CET, Jan Beulich wrote:
> On 12.02.2026 19:29, Alejandro Vallejo wrote:
>> On Wed Jan 28, 2026 at 3:35 PM CET, Jason Andryuk wrote:
>>> On 2025-04-01 06:58, Jan Beulich wrote:
>>>> Leverage the new infrastructure in xen/linkage.h to also switch to per-
>>>> function sections (when configured), deriving the specific name from the
>>>> "base" section in use at the time FUNC() is invoked.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> Tested-by: Luca Fancellu <luca.fancellu@xxxxxxx> # arm
>> 
>> I don't seem to have the original patch in my inbox, so I'll just answer 
>> here.
>> 
>> About the assembly modifications on the exception entry points:
>> 
>> With split sections the linker is free to reorder all of them as it sees fit,
>> which probably means we want int3 after every jump to prevent straight-line
>> speculation from allocating an XSA number for us. It's possible the linker 
>> might
>> inject them, but it might also not. Better to err on the side of caution.
>
> We're lacking such INT3 elsewhere, hence why this is the topic of separate
> (existing) work.

Maybe so, but split sections changes things qualitatively in that now you don't
really know what's after the exception entry point. Previously, if the CPU was
to speculate ahead in most exception they'd eventually hit the spec mitigations
of entry_DF before being able to reach anywhere truly dangerous. entry_PF's
straight line led to the mitigations too. Same with NMI...

Having them all in separate sections shuffled at the linker's will is way too
dangerous, IMO. We clearly need individual function markers for livepatching,
but section-wise it's fine to put everything that can't possibly be GCd in a
single section.

> See how, for example, we're also not using -mharden-sls=all.

Hmm. I can see how -mharden-sls=all might impact perf in places we don't want,
but surely -mharden-sls=return can only be good?

> See e.g. [1] for a very old posting. Even in my outbox I can't find newer
> postings covering more stuff. Intermediately some of this was posted to
> security@ only, but there clearly was the plan to have all of this in public.

Thanks for the context.

That'd address the speculation problem, but we'd still suffer branches in
avoidable places.

It'd be nice to have a general means preventing dangerous SLS, but that's
largely orthogonal to the new challenges that arise with split sections, I
think.

>
>> Though more generally, I'd just keep all exception entry points in the same
>> section. They'd never get GC'ed anyway and we're paying an extra branch in 
>> the
>> #PF path for no reason.
>
> Inserting a branch there was, iirc, asked for by someone independent of this
> work. But yes, suppressing too fine grained section splits is an option.

My .02 is that splitting that which cannot be GCd serves no purpose and
increases the cognitive burden of an already very complex system.

>
> Jan
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2020-11/msg01542.html

Cheers,
Alejandro