From nobody Fri Nov 29 02:55:44 2024 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) (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 853AC19AA53 for ; Wed, 25 Sep 2024 15:02:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727276576; cv=none; b=CKikvgMrtoEzrDwBoHRLJsq83NZ7+/TYGES6Vqrf4nO60zulRh0EAhIxowNdU970s/DUcZFstCAqz9L6P93+ivtQ6BcaTIa0TOflLH0rEOHLsJNITRghD5/RdBtncmgcUGB2Abasqy+7PEHkoXqpBaCkReeQx3Ge8Z+Ha3du4BQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727276576; c=relaxed/simple; bh=31w9JHpb/FOSX9EXfChPlaKIxGcZxzD1C7F5EPjfIx4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=lQvCH0ICzWkigG5ksTwyB9fNejh557FWusHMV5NKgtog6WynCu3b6Y7aZFFXb1yhsM538p7Dr8xh7qxj70DhYemz0dfuR/U6Nx8ILhEgsfoCaU4vchxme7/KKCvZXWtRPxrEYhfqR0eLeWGILhIR7fHVFHzL6Op9fltpJnM+zlg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--ardb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=w+eQ9FA0; arc=none smtp.client-ip=209.85.128.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--ardb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="w+eQ9FA0" Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-6db7a8c6910so102668607b3.0 for ; Wed, 25 Sep 2024 08:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727276572; x=1727881372; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=q7Siui3EQaHZbOP2Zf5u6bj1Z6F9xVc5htz8ViId7Yw=; b=w+eQ9FA0GHYJxNAkHx1mPkBCi8HnHJsS0BO2cqHqm9CxqwrOyv8yy9KCeHX9MPqrzD WS9F8awA4YQB1ioGO1mN4KYKqar9hOhf4KVwKcEFsPXO8r29khQ8Kl/6T2gjIfM6OK5l 1/jgqXc8G0q+vd2TZlBys/SWH1S8HQ2PZt1bpq5Xj+ieKrqR2i0WVtg6QZrv9g1LiRgg 0vyGmM5+XXz2LIHNn9bFbVtRBbGDoxksdqaBIkM9gVoomZ3RnD71aqDyQGosKbiNy579 lFYPlUJHdYzzUkbfGXvLJHP5uDGhkX6PWPQqK4zmsL96SVNwW49cfY7JJV8dcVrPCmzA MY0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727276572; x=1727881372; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=q7Siui3EQaHZbOP2Zf5u6bj1Z6F9xVc5htz8ViId7Yw=; b=LA+BYi20xA1seUmpZWI913EaeZaZ1lzGL7QAuZJuoCLaqzKcOk99CvwsEwNWSGFtSr WJLjJs92I7BeAf0OSMaZsjYmR2NJa2Mu1ubX05+3wo7My7C+wHpimHm+X9ByiG7wFn/Z q9n4MvQkCIT+PbE7q4sDFYycLvBNgZzT8hhoJTfxGzMJLiHOY5Ra5AqVdREGlhoSRrL6 DYH+ZaAUbN0k106eH+jM/Fl05GmEKS7GvX2nvMMRV06utkm6bnXVC4MX+q8FKdPaQ+Ow nrV4Jhu+r5x+lV/bVYtAEk8vrZ8w3pM4JhBTbfWCl0CQ7FksXiNDbfBQzYIZhFoMWuxx 9ARg== X-Gm-Message-State: AOJu0YwxP5rSbKe3/UMZovhOWquui6Yg0iQesLpfTnqn7l6BEzUz5rKf kR6WhBj7LkfuxDTsQaju7IdRbjO5/RSDxk7cJwislXyu+2mDqJqn4NWjlL+LvimCkeanJfLCAqJ pOO4egAVxwFaMg5ojk+gpNYHO4wkr4AMgDkNB/2f9sEHM0tgW8xWItmjD+WUvi/7at9QlZ4I54c hW5s/WqEnDZrUdIYBTtUg+hurKHjVm2Q== X-Google-Smtp-Source: AGHT+IGUGK/IbClqwN6y6QvmI8hCfQn6s2hVSiVHB1d+dhN6jVJxxhzTiRxXUiYwgEqTcxKFspPDWKFo X-Received: from palermo.c.googlers.com ([fda3:e722:ac3:cc00:7b:198d:ac11:8138]) (user=ardb job=sendgmr) by 2002:a05:690c:f90:b0:6c1:298e:5a7 with SMTP id 00721157ae682-6e21d9f2676mr100587b3.5.1727276571410; Wed, 25 Sep 2024 08:02:51 -0700 (PDT) Date: Wed, 25 Sep 2024 17:01:24 +0200 In-Reply-To: <20240925150059.3955569-30-ardb+git@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240925150059.3955569-30-ardb+git@google.com> X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Developer-Signature: v=1; a=openpgp-sha256; l=2378; i=ardb@kernel.org; h=from:subject; bh=s5eg4POBUMz0+xutAa57cnb7wChxapKHTEsRfaj5xkM=; b=owGbwMvMwCFmkMcZplerG8N4Wi2JIe2L6rmrbx/K9pd0n9poZ7rKarM71/pb64Mu3OE7WFCew +trFZHXUcrCIMbBICumyCIw+++7nacnStU6z5KFmcPKBDKEgYtTACYiIMfIsHzp8ptxntWap0qz /54LMvVhTo1RvbxcftLGA6VFgfY+Jxn+B/cyx9dHTT/wO+rQQaXszxPMFk1geHr9aqrVTv/NPxI dmAE= X-Mailer: git-send-email 2.46.0.792.g87dc391469-goog Message-ID: <20240925150059.3955569-54-ardb+git@google.com> Subject: [RFC PATCH 24/28] tools/objtool: Treat indirect ftrace calls as direct calls From: Ard Biesheuvel To: linux-kernel@vger.kernel.org Cc: Ard Biesheuvel , x86@kernel.org, "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Uros Bizjak , Dennis Zhou , Tejun Heo , Christoph Lameter , Mathieu Desnoyers , Paolo Bonzini , Vitaly Kuznetsov , Juergen Gross , Boris Ostrovsky , Greg Kroah-Hartman , Arnd Bergmann , Masahiro Yamada , Kees Cook , Nathan Chancellor , Keith Packard , Justin Stitt , Josh Poimboeuf , Arnaldo Carvalho de Melo , Namhyung Kim , Jiri Olsa , Ian Rogers , Adrian Hunter , Kan Liang , linux-doc@vger.kernel.org, linux-pm@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org, linux-efi@vger.kernel.org, linux-arch@vger.kernel.org, linux-sparse@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-perf-users@vger.kernel.org, rust-for-linux@vger.kernel.org, llvm@lists.linux.dev Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ard Biesheuvel In some cases, the compiler may rely on indirect calls using GOT slots as memory operands to emit function calls. This leaves it up to the linker to relax the call to a direct call if possible, i.e., if the destination address is known at link time and in range, which may not be the case when building shared libraries for user space. On x86, this may happen when building in PIC mode with ftrace enabled, and given that vmlinux is a fully linked binary, this relaxation is always possible, and therefore mandatory per the x86_64 psABI. This means that the indirect calls to __fentry__ that are observeable in vmlinux.o will have been converted to direct calls in vmlinux, and can be treated as such by objtool. Signed-off-by: Ard Biesheuvel --- tools/objtool/check.c | 32 ++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 04725bd83232..94a56099e22d 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -1696,11 +1696,39 @@ static int add_call_destinations(struct objtool_fil= e *file) struct reloc *reloc; =20 for_each_insn(file, insn) { - if (insn->type !=3D INSN_CALL) + if (insn->type !=3D INSN_CALL && + insn->type !=3D INSN_CALL_DYNAMIC) continue; =20 reloc =3D insn_reloc(file, insn); - if (!reloc) { + if (insn->type =3D=3D INSN_CALL_DYNAMIC) { + if (!reloc) + continue; + + /* + * GCC 13 and older on x86 will always emit the call to + * __fentry__ using a relaxable GOT-based symbol + * reference when operating in PIC mode, i.e., + * + * call *0x0(%rip) + * R_X86_64_GOTPCRELX __fentry__-0x4 + * + * where it is left up to the linker to relax this into + * + * call __fentry__ + * nop + * + * if __fentry__ turns out to be DSO local, which is + * always the case for vmlinux. Given that this + * relaxation is mandatory per the x86_64 psABI, these + * calls can simply be treated as direct calls. + */ + if (arch_ftrace_match(reloc->sym->name)) { + insn->type =3D INSN_CALL; + add_call_dest(file, insn, reloc->sym, false); + } + + } else if (!reloc) { dest_off =3D arch_jump_destination(insn); dest =3D find_call_destination(insn->sec, dest_off); =20 --=20 2.46.0.792.g87dc391469-goog