Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 3/3] objtool: Add relocation check for alternative
 sections
To:     Josh Poimboeuf <jpoimboe@redhat.com>, x86@kernel.org
Cc:     linux-kernel@vger.kernel.org, Borislav Petkov <bp@suse.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
References: <cover.1581359535.git.jpoimboe@redhat.com>
 <7b90b68d093311e4e8f6b504a9e1c758fd7e0002.1581359535.git.jpoimboe@redhat.com>
From:   Julien Thierry <jthierry@redhat.com>
Message-ID: <1bc9dfd5-0652-c5e1-7ab2-cdd025edc01b@redhat.com>
Date:   Tue, 11 Feb 2020 08:16:01 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <7b90b68d093311e4e8f6b504a9e1c758fd7e0002.1581359535.git.jpoimboe@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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@linux-foundation.org>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.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@redhat.com>

Cheers,

-- 
Julien Thierry