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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210819232437.3g6dpalylgn7fgrx@treble>
Date:   Thu, 19 Aug 2021 16:24:37 -0700
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Joe Lawrence <joe.lawrence@...hat.com>
Cc:     x86@...nel.org, Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, Miroslav Benes <mbenes@...e.cz>
Subject: Re: [PATCH] objtool: x86: .altinstructions doesn't need section
 entry size

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@...hat.com>
> ---
> 
> Hi Josh, this is a follow up for
> https://github.com/dynup/kpatch/issues/1194 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.

-- 
Josh