linux-kernel - Re: [PATCH 3/3] objtool: Add relocation check for alternative sections

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1bc9dfd5-0652-c5e1-7ab2-cdd025edc01b@redhat.com>
Date:   Tue, 11 Feb 2020 08:16:01 +0000
From:   Julien Thierry <jthierry@...hat.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>, x86@...nel.org
Cc:     linux-kernel@...r.kernel.org, Borislav Petkov <bp@...e.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 3/3] objtool: Add relocation check for alternative
 sections



On 2/10/20 6:32 PM, Josh Poimboeuf wrote:
> Relocations in alternative code can be dangerous, because the code is
> copy/pasted to the text section after relocations have been resolved,
> which can corrupt PC-relative addresses.
> 
> However, relocations might be acceptable in some cases, depending on the
> architecture.  For example, the x86 alternatives code manually fixes up
> the target addresses for PC-relative jumps and calls.
> 
> So disallow relocations in alternative code, except where the x86 arch
> code allows it.
> 
> This code may need to be tweaked for other arches when objtool gets
> support for them.
> 
> Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org>
> Signed-off-by: Josh Poimboeuf <jpoimboe@...hat.com>
> ---
>   tools/objtool/check.c | 21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)
> 
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 5ea2ce7ed8a3..2d52a40e6cb9 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -786,6 +786,27 @@ static int handle_group_alt(struct objtool_file *file,
>   		insn->ignore = orig_insn->ignore_alts;
>   		insn->func = orig_insn->func;
>   
> +		/*
> +		 * Since alternative replacement code is copy/pasted by the
> +		 * kernel after applying relocations, generally such code can't
> +		 * have relative-address relocation references to outside the
> +		 * .altinstr_replacement section, unless the arch's
> +		 * alternatives code can adjust the relative offsets
> +		 * accordingly.
> +		 *
> +		 * The x86 alternatives code adjusts the offsets only when it
> +		 * encounters a branch instruction at the very beginning of the
> +		 * replacement group.

Yes, arm64 is a bit more permissive regarding this although it does 
disallow some patterns.

I guess once we introduce other archs there should be some function:

bool arch_validate_alt_insn(struct instruction *new, struct instruction 
*new, struct special_alt *alt);

> +		 */
> +		if ((insn->offset != special_alt->new_off ||
> +		    (insn->type != INSN_CALL && !is_static_jump(insn))) &&
> +		    find_rela_by_dest_range(insn->sec, insn->offset, insn->len)) {
> +
> +			WARN_FUNC("unsupported relocation in alternatives section",
> +				  insn->sec, insn->offset);
> +			return -1;
> +		}
> +
>   		if (!is_static_jump(insn))
>   			continue;
>   
> 

Reviewed-by: Julien Thierry <jthierry@...hat.com>

Cheers,

-- 
Julien Thierry