Re: [PATCH] objtool: x86: .altinstructions doesn't need section entry size

From: Josh Poimboeuf
Date: Thu Aug 19 2021 - 19:24:45 EST

On Mon, Aug 16, 2021 at 09:49:58PM -0400, Joe Lawrence wrote:
> commit e31694e0a7a7 ("objtool: Don't make .altinstructions writable")
> aligned objtool-created and kernel-created .altinstructions section
> flags, but there remains a minor discrepency in their use of a section
> entry size: objtool sets one while the kernel build does not.

I'd recommend more of an "active voice" subject like:

objtool: Make .altinstructions section entry size consistent

> While sh_entsize of sizeof(struct alt_instr) seems intuitive, this small
> deviation can cause failures with external tooling like kpatch-build.
> Fix this by creating new .altinstructions sections with sh_entsize of 0
> and then later updating sec->len as alternatives are added to the
> section. An added benefit is avoiding the data descriptor and buffer
> created by elf_create_section(), but previously unused by
> elf_add_alternative().
> Fixes: 9bc0bb50727c ("objtool/x86: Rewrite retpoline thunk calls")
> Signed-off-by: Joe Lawrence <joe.lawrence@xxxxxxxxxx>
> ---
> Hi Josh, this is a follow up for
> where I'll add some more
> comments on the kpatch-side of this. We could probably work around it
> over there, but this objtool tweak looks small enough to maintain closer
> kernel-built .altinstructions section properties.
> tools/objtool/arch/x86/decode.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
> index bc821056aba9..e7087aa473f8 100644
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -684,7 +684,7 @@ static int elf_add_alternative(struct elf *elf,
> sec = find_section_by_name(elf, ".altinstructions");
> if (!sec) {
> sec = elf_create_section(elf, ".altinstructions",
> - SHF_ALLOC, size, 0);
> + SHF_ALLOC, 0, 0);

Looks good.

> if (!sec) {
> WARN_ELF("elf_create_section");
> @@ -692,6 +692,8 @@ static int elf_add_alternative(struct elf *elf,
> }
> }
> + sec->len += size;
> +

This latter change makes sense, but I'm not sure it belongs in this
patch. Wasn't sec->len wrongly set to zero (and never incremented) even
before this patch?

>From what I can tell sec->len isn't ever read for this section, so it
seems to be more of a previously existing theoretical bug, independent
of the entsize mismatch bug. In which case it's still worth fixing,
just probably in a separate patch.

Also the sec->len update should probably be moved down to the bottom of
the function alongside the update to sec->sh.sh_size, as sec->len is a
"convenient" more readable mirror copy of sec->sh.sh_size.

Actually, mirroring sec->sh.sh_size was a bad idea. It's guaranteed to
introduce dumb bugs like this. Maybe we should just kill sec->len
altogether in favor of using sec->sh.sh_size everywhere.