From nobody Mon Feb 9 16:17:08 2026 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C9D247A7F for ; Wed, 27 Mar 2024 09:45:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711532713; cv=none; b=pQ4KC9NNYrFsM6aiLl986e8maf3QKuqozNTaSTbkO+U/bgitsN+76bzN/Kob1Hj7oPg5cLR0u38WsWwNW3cqnaEzsUdYwaoNEjCstiXo1PYSGrQO+8XENfeK0mKkEX5IgbF1KWaRK0RufsU+bkLdpO9eA05ahY/HIgRjMflmWrc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711532713; c=relaxed/simple; bh=mz+bosMKw7JEpeaxuTDFds5WFr4SLDM7h7W8b2VLQOo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=UAytuybrndEM0CBe6DBc5r9sR4nWvWiKquUz7kKsCPi9VBXMQT4ySDPiT2oBfEw0Q1IPVMYyz+1kqcy8zRwhvXhq060YCeR/oA5vc/ffNiumnl6Bh3orBAGpXNmnbxbR/Oe1d4C64h/QYxYpZKnwKXzHANxk/riN6fSrWU4Idg8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=GeD/Uekp; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="GeD/Uekp" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1e0f0398553so15259465ad.3 for ; Wed, 27 Mar 2024 02:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1711532711; x=1712137511; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wSpDjbqI0gNW8wl9pMQX51obps/WN2ZG0m8/65kcflw=; b=GeD/UekpMeUOUpvp4xGkmLZpXhT3OSC/LiOznVGvJXlwZAcRaPOeEw7T9hoM0WFgPl lN8b41vkJXS71+iv+D0IhGXYjYpbgUF/08yhOZFjAD4TrSaWui4LJTGs0rphibjoznnB Hb04N0awRX/EOjKgTS2NxQ9izX01n+GtfGvH6CF2I8iqttg7a5xuUkyONvex6ziUxi1i r6SC0PoKKT8htPCyUkZvWZSBiW3Wd3entvR0je7JXe7rCcR7RNMazkgb2vSPQx4mYDs3 j90YeQ/zdaUJUc3NBD2Y393byL6apJ3MhJigc3BiHthB5ECyie15T2ZtVnTJB7HAtnBV sB1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711532711; x=1712137511; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wSpDjbqI0gNW8wl9pMQX51obps/WN2ZG0m8/65kcflw=; b=Rr81dKScASh5MgzluAoaBma1r337EqSyMxBJ2F8IpglIEnl/qcpL77i6Rpm+lpxu+q Cz3fl45NezlexwyGLUFEE/lHzhjAOicF7s5U0hy86KmXiILxnHBRTA6Ux2kb7IgNPRnh UQFUzsuNyl/ElCNiCwxMZgi35501eo0z0fLngN9U9laASe9lyqgXSe1Meyplq/twi65f caMYcTU4HcJkBRIAXonZXs1LHdIHIWsmgU1vKmHh9esHg735hztQqj30q+E4yAeRuL3f uVtRxkV5R8g4crBLezMKs4laNvPfjF3Bomka/4qOpUEN5PpAKuYT4tTnvcLfeW/WDpbE /RxQ== X-Forwarded-Encrypted: i=1; AJvYcCVTeVFBTpT8xy3yqdyFW4bbmGrID72VJDqF+OWuolWP+NsBZ941TyumK3B+XTmEzYuW8tSWAJEf5V6yyePpovIa4ZugaoMZNsJV3td3 X-Gm-Message-State: AOJu0YxRC1vLQqr61cz36e/HMMgO9h5HtHCNE9jJ2fNpY40NEDZKTClr 6K/FmyVaXx6tPhEXtZ9JDnv1ZxF2td5ESjDaVeS/ISsAeD/stvjLZUZQiKOlaSU= X-Google-Smtp-Source: AGHT+IFdVDHbIoG5YdoUPPxQ2dLnkaDd5QNngmb4cTws7m6JzWC9vxMjf4HuAdLVk3ehR0tkklUr/w== X-Received: by 2002:a17:903:1109:b0:1dc:7bc:d025 with SMTP id n9-20020a170903110900b001dc07bcd025mr751427plh.4.1711532710850; Wed, 27 Mar 2024 02:45:10 -0700 (PDT) Received: from C02CV19DML87.bytedance.net ([2001:c10:ff04:0:1000:0:1:7]) by smtp.gmail.com with ESMTPSA id q3-20020a170902e30300b001e002673fddsm8500474plc.194.2024.03.27.02.45.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 02:45:10 -0700 (PDT) From: Rui Qi To: bp@alien8.de, mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, jpoimboe@redhat.com, peterz@infradead.org, mbenes@suse.cz, gregkh@linuxfoundation.org, stable@vger.kernel.org, alexandre.chartre@oracle.com Cc: x86@kernel.org, linux-kernel@vger.kernel.org, sashal@kernel.org, Rui Qi Subject: [PATCH V3 RESEND 2/3] objtool: Add support for intra-function calls Date: Wed, 27 Mar 2024 17:44:46 +0800 Message-Id: <20240327094447.47375-3-qirui.001@bytedance.com> X-Mailer: git-send-email 2.39.2 (Apple Git-143) In-Reply-To: <20240327094447.47375-1-qirui.001@bytedance.com> References: <20240327094447.47375-1-qirui.001@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexandre Chartre commit 8aa8eb2a8f5b3305a95f39957dd2b715fa668e21 upstream. Change objtool to support intra-function calls. On x86, an intra-function call is represented in objtool as a push onto the stack (of the return address), and a jump to the destination address. That way the stack information is correctly updated and the call flow is still accurate. Signed-off-by: Alexandre Chartre Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Miroslav Benes Acked-by: Josh Poimboeuf Link: https://lkml.kernel.org/r/20200414103618.12657-4-alexandre.chartre@or= acle.com Signed-off-by: Rui Qi --- include/linux/frame.h | 11 ++++ .../Documentation/stack-validation.txt | 8 +++ tools/objtool/arch/x86/decode.c | 6 ++ tools/objtool/check.c | 62 +++++++++++++++++-- 4 files changed, 83 insertions(+), 4 deletions(-) diff --git a/include/linux/frame.h b/include/linux/frame.h index 02d3ca2d9598..303cda600e56 100644 --- a/include/linux/frame.h +++ b/include/linux/frame.h @@ -15,9 +15,20 @@ static void __used __section(.discard.func_stack_frame_non_standard) \ *__func_stack_frame_non_standard_##func =3D func =20 +/* + * This macro indicates that the following intra-function call is valid. + * Any non-annotated intra-function call will cause objtool to issue a war= ning. + */ +#define ANNOTATE_INTRA_FUNCTION_CALL \ + 999: \ + .pushsection .discard.intra_function_calls; \ + .long 999b; \ + .popsection; + #else /* !CONFIG_STACK_VALIDATION */ =20 #define STACK_FRAME_NON_STANDARD(func) +#define ANNOTATE_INTRA_FUNCTION_CALL =20 #endif /* CONFIG_STACK_VALIDATION */ =20 diff --git a/tools/objtool/Documentation/stack-validation.txt b/tools/objto= ol/Documentation/stack-validation.txt index de094670050b..ee26bb382b70 100644 --- a/tools/objtool/Documentation/stack-validation.txt +++ b/tools/objtool/Documentation/stack-validation.txt @@ -290,6 +290,14 @@ they mean, and suggestions for how to fix them. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D70646 =20 =20 +11. file.o: warning: unannotated intra-function call + + This warning means that a direct call is done to a destination which + is not at the beginning of a function. If this is a legit call, you + can remove this warning by putting the ANNOTATE_INTRA_FUNCTION_CALL + directive right before the call. + + If the error doesn't seem to make sense, it could be a bug in objtool. Feel free to ask the objtool maintainer for help. =20 diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decod= e.c index a62e032863a8..c3ff62c085c8 100644 --- a/tools/objtool/arch/x86/decode.c +++ b/tools/objtool/arch/x86/decode.c @@ -437,6 +437,12 @@ int arch_decode_instruction(struct elf *elf, struct se= ction *sec, =20 case 0xe8: *type =3D INSN_CALL; + /* + * For the impact on the stack, a CALL behaves like + * a PUSH of an immediate value (the return address). + */ + op->src.type =3D OP_SRC_CONST; + op->dest.type =3D OP_DEST_PUSH; break; =20 case 0xfc: diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 71a24fd46dbd..0fa414869f45 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -645,6 +645,7 @@ static int add_jump_destinations(struct objtool_file *f= ile) return 0; } =20 + /* * Find the destination instructions for all calls. */ @@ -666,10 +667,7 @@ static int add_call_destinations(struct objtool_file *= file) dest_off); =20 if (!insn->call_dest && !insn->ignore) { - WARN_FUNC("unsupported intra-function call", - insn->sec, insn->offset); - if (retpoline) - WARN("If this is a retpoline, please patch it in with alternatives an= d annotate it with ANNOTATE_NOSPEC_ALTERNATIVE."); + WARN_FUNC("unannotated intra-function call", insn->sec, insn->offset); return -1; } =20 @@ -1291,6 +1289,58 @@ static int read_retpoline_hints(struct objtool_file = *file) return 0; } =20 + +static int read_intra_function_calls(struct objtool_file *file) +{ + struct instruction *insn; + struct section *sec; + struct rela *rela; + + sec =3D find_section_by_name(file->elf, ".rela.discard.intra_function_cal= ls"); + if (!sec) + return 0; + + list_for_each_entry(rela, &sec->rela_list, list) { + unsigned long dest_off; + + if (rela->sym->type !=3D STT_SECTION) { + WARN("unexpected relocation symbol type in %s", + sec->name); + return -1; + } + + insn =3D find_insn(file, rela->sym->sec, rela->addend); + if (!insn) { + WARN("bad .discard.intra_function_call entry"); + return -1; + } + + if (insn->type !=3D INSN_CALL) { + WARN_FUNC("intra_function_call not a direct call", + insn->sec, insn->offset); + return -1; + } + + /* + * Treat intra-function CALLs as JMPs, but with a stack_op. + * See add_call_destinations(), which strips stack_ops from + * normal CALLs. + */ + insn->type =3D INSN_JUMP_UNCONDITIONAL; + + dest_off =3D insn->offset + insn->len + insn->immediate; + insn->jump_dest =3D find_insn(file, insn->sec, dest_off); + if (!insn->jump_dest) { + WARN_FUNC("can't find call dest at %s+0x%lx", + insn->sec, insn->offset, + insn->sec->name, dest_off); + return -1; + } + } + + return 0; +} + static void mark_rodata(struct objtool_file *file) { struct section *sec; @@ -1346,6 +1396,10 @@ static int decode_sections(struct objtool_file *file) if (ret) return ret; =20 + ret =3D read_intra_function_calls(file); + if (ret) + return ret; + ret =3D add_call_destinations(file); if (ret) return ret; --=20 2.20.1