Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation

Linus Torvalds
2022-07-18T22:35:20Z

On Mon, Jul 18, 2022 at 2:43 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> FWIW, when I was poking at this last week, I found that -falign-function
> only seems to apply to the normal .text section and not to random other
> sections with text we create.
>
> Or rather, I was seeind a lot of unaligned functions that all had custom
> sections despite explicitly using the (what I thought was a global)
> function alignment toggle.

Hmm. This triggers a memory..

I think we may have two different issues at play.

One is that I think our linker script only aligns code sections to 8
bytes by default. Grep for ALIGN_FUNCTION.

And I think that any .align directive (or .p2align) only aligns
relative to that section, so if the section itself wasn't aligned, it
doesn't help to have some alignment within the section.

I may be wrong.

But I can definitely see gcc not aligning functions too, and doing a

nm vmlinux | grep ' t ' | grep -v '0 t ' | grep -v '\.cold$' | sort

shows a _lot_ of them for me.

I think the main cause is that the ACPI code builds with

ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA

and that '-Os' will disable all function alignment. I think there's a
few other places that do that too.

I don't see the same effect in my clang build, so I think that -Os
behavior is likely gcc-specific.

In my clang build, I do see a few unaligned function symbols, but they
seem to be all our own assembler ones (eg "nested_nmi") and they seem
to be intentional (ie that "nested_nmi" thing is in the middle of the
"asm_exc_nmi" function, which is the real thing and which _is_
aligned).

Linus