Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp1369844imi; Sat, 23 Jul 2022 03:57:03 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t5r8J3hRL61MGKK00SHr366XBNSd1VNikpNrp8oBAsfhZy7t9bEy69cAnbPpPdUHT2thtK X-Received: by 2002:a05:6a02:302:b0:415:fa99:e0aa with SMTP id bn2-20020a056a02030200b00415fa99e0aamr3407787pgb.516.1658573823113; Sat, 23 Jul 2022 03:57:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658573823; cv=none; d=google.com; s=arc-20160816; b=HeZZ0/H40d9sEqUtQYGiBq80SYut1Nip3tMR+jSpxmmOAiqOuXOuENrCXM/zOLUqoZ t2m9QcNSIhJlayx506KLUZdqD4PqaBr/LJKcGcEycbWlpW2wYKcs0uqJxMs6n3olLMew DP+vUzKcn5uA1BE6/m1PBm7tvUTTQoUCzK7Vsz0Xv75HtKjonN9K/k7KkplmGv7wrLZ0 QsISnssAqVxUA7DMYJBJAn5jeBZ6SWcbajz4wbTj59qYZT5U3G2bHJFQvqpUZ5PrfbXq rACv3DV5hasQtE80P6lVfyDEDTzhoM9gl1z9lfZrjKB8lOxYPBR+PogEUUqdYwwKJgld Gg2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=kfjnlXRlhLnjmmumRGr7BVc0/otGZx4l+4tJ5daxh8M=; b=DWv8/ch4EkM4FxMvljnc6QfI+e1w8KGo/cmDPe60KNkUSSFERG6CSDdaN1vFdAHmOa WaG/P7iiZ2dYQ0+tjQVxRV5vlKMIHVQlFzqqCAqfAGkoZhJ3RiNyVZw4sEk3Qgd7Kxs6 TmKSptfqyvQoKrbvir60Buau8ZQgTSullHVkMrPn6SaAhJYHv/aFgqXXvLCAescQOoQU XbVZBUiqUUO620mHT4c28uEYs4EAlGSRaBaCJVz6K/ZsPhlfZvKwqVTdhMksemVMYsKO vJ+eYEjdASuQXxxWYsoWShdT+dJTI3orvYH4a4rZ/pVJK8epkr3Hl3arQ8+/ANLiccyE FK/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qeEAPTGZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o3-20020a170903300300b0016c66bf1a15si7318908pla.34.2022.07.23.03.56.48; Sat, 23 Jul 2022 03:57:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qeEAPTGZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237925AbiGWKD6 (ORCPT + 99 others); Sat, 23 Jul 2022 06:03:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237984AbiGWKDc (ORCPT ); Sat, 23 Jul 2022 06:03:32 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1AD18AB09; Sat, 23 Jul 2022 02:59:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 2959FCE0DBE; Sat, 23 Jul 2022 09:59:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15F5AC341C0; Sat, 23 Jul 2022 09:59:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1658570355; bh=b4lPAu6TIYBuJvohHsBAYnRu4yFmScVttnEgCBbUYFc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qeEAPTGZAHiw/D/G50afSWGdRyQsAwDowupN8hjN4fNVsJNhYuJAnAHmAy3xRgx/I WgiRd5WwllDq12dTLoK7y5x5SzeSpZ+IV455YrqZ5dNVdYVBUb2A63f+WZG4MUGjv9 uFDYj/9epltV5F//86tMeCqS9qwtLDSuMQii0uAk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Peter Zijlstra (Intel)" , Borislav Petkov , Josh Poimboeuf , Alexei Starovoitov , Thadeu Lima de Souza Cascardo , Ben Hutchings Subject: [PATCH 5.10 048/148] objtool: Explicitly avoid self modifying code in .altinstr_replacement Date: Sat, 23 Jul 2022 11:54:20 +0200 Message-Id: <20220723095237.747602693@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220723095224.302504400@linuxfoundation.org> References: <20220723095224.302504400@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Peter Zijlstra commit dd003edeffa3cb87bc9862582004f405d77d7670 upstream. Assume ALTERNATIVE()s know what they're doing and do not change, or cause to change, instructions in .altinstr_replacement sections. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Borislav Petkov Acked-by: Josh Poimboeuf Tested-by: Alexei Starovoitov Link: https://lore.kernel.org/r/20211026120309.722511775@infradead.org [cascardo: context adjustment] Signed-off-by: Thadeu Lima de Souza Cascardo [bwh: Backported to 5.10: objtool doesn't have any mcount handling] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman --- tools/objtool/check.c | 36 ++++++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 8 deletions(-) --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -870,18 +870,27 @@ static void remove_insn_ops(struct instr } } -static void add_call_dest(struct objtool_file *file, struct instruction *insn, - struct symbol *dest, bool sibling) +static void annotate_call_site(struct objtool_file *file, + struct instruction *insn, bool sibling) { struct reloc *reloc = insn_reloc(file, insn); + struct symbol *sym = insn->call_dest; - insn->call_dest = dest; - if (!dest) + if (!sym) + sym = reloc->sym; + + /* + * Alternative replacement code is just template code which is + * sometimes copied to the original instruction. For now, don't + * annotate it. (In the future we might consider annotating the + * original instruction if/when it ever makes sense to do so.) + */ + if (!strcmp(insn->sec->name, ".altinstr_replacement")) return; - if (insn->call_dest->static_call_tramp) { - list_add_tail(&insn->call_node, - &file->static_call_list); + if (sym->static_call_tramp) { + list_add_tail(&insn->call_node, &file->static_call_list); + return; } /* @@ -889,7 +898,7 @@ static void add_call_dest(struct objtool * so they need a little help, NOP out any KCOV calls from noinstr * text. */ - if (insn->sec->noinstr && insn->call_dest->kcov) { + if (insn->sec->noinstr && sym->kcov) { if (reloc) { reloc->type = R_NONE; elf_write_reloc(file->elf, reloc); @@ -901,7 +910,16 @@ static void add_call_dest(struct objtool : arch_nop_insn(insn->len)); insn->type = sibling ? INSN_RETURN : INSN_NOP; + return; } +} + +static void add_call_dest(struct objtool_file *file, struct instruction *insn, + struct symbol *dest, bool sibling) +{ + insn->call_dest = dest; + if (!dest) + return; /* * Whatever stack impact regular CALLs have, should be undone @@ -911,6 +929,8 @@ static void add_call_dest(struct objtool * are converted to JUMP, see read_intra_function_calls(). */ remove_insn_ops(insn); + + annotate_call_site(file, insn, sibling); } /*