Message ID | bc3344e51f3e87102f1301a0be0f72a7689ea4a4.1681331135.git.jpoimboe@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp584879vqo; Wed, 12 Apr 2023 13:28:58 -0700 (PDT) X-Google-Smtp-Source: AKy350b1CbuDAyxk5K7CL135nh/21moZxxPDVzEssX0kVCAxHmwa+ruwRVzSZ7JcWP74c3PwrTyv X-Received: by 2002:a05:6402:1608:b0:504:92aa:12ee with SMTP id f8-20020a056402160800b0050492aa12eemr3740596edv.15.1681331338288; Wed, 12 Apr 2023 13:28:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681331338; cv=none; d=google.com; s=arc-20160816; b=1KsfSYMY3duXUwsXGi4TahMXpYvB+3fi6WR2XEZd1PCoqr8GCEPLilqa/DOKbvKSpd I07BeI+g2Zmp+lGCA/KuxBhvhl/kpA0et9jkdZ4UdjiLJBipQPesI+KyVJACQSIHcnQy FpFSjS+PYgyfgBIfztte4XsIXbTeSR+dJTKHUgpRvNkLhqJ2CwbX/6V8gJ+obrN0ZS8D ivD26G2nO1yRzPvNiXaxTie/5d0jhqz763HNX+7N/yUE3BDBpa+M0lCRHzEvqwMattVX Ik1GW/nzEJwkffCu7KVOH186ska0ZPGT2QFX+IUrQHtxYf9OuHRL4qdyGG81ZLbqFkQW rnLQ== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=RgP29RvCH7uU1Rd8NUq7EMbGXTC7mbRrwzgoggKrhZw=; b=E/IcQuRGky92vl9Q/haaBR/Brgua6bjJmUz8wPeEVk3SFPB0IAZ4FsxCwoBIWB7w4l rUI4bvqZIL5AS/q8lNvZ98LQc9C9STzSgyj4sJcVMDokC/HswWz+XjOc2J5vyRN92KhU fy2iUD2ipmc15VCNOchX3aImJRVTdA1R1PqctgUpNeXCY2Ps0B3OFIVLnuzUylHiMSJ/ hjN7PO02mjhZCN5k3iE3tsdlw8CvSTrUcACjghQmJ7LAjJBwddiMVKKJttXJlt6QVCkK 5mXMjC38949MNmT1DCIaIKXm2uZZBZ3XgJ2xIBp8a6YJEHtgTpG6TfdKUyrpq7qSc0VH lhyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pGh8C+Wj; 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=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y1-20020a50e601000000b00501d531b215si15129711edm.522.2023.04.12.13.28.34; Wed, 12 Apr 2023 13:28:58 -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=@kernel.org header.s=k20201202 header.b=pGh8C+Wj; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229667AbjDLU0c (ORCPT <rfc822;peter110.wang@gmail.com> + 99 others); Wed, 12 Apr 2023 16:26:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229762AbjDLU0Y (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 12 Apr 2023 16:26:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 89FE410DC for <linux-kernel@vger.kernel.org>; Wed, 12 Apr 2023 13:26:23 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 1EC2F631DF for <linux-kernel@vger.kernel.org>; Wed, 12 Apr 2023 20:26:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C79FC433A4; Wed, 12 Apr 2023 20:26:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681331182; bh=zo0BxAzMtQYruLjF5XaJiSkqwASG0OADnk73jUKYYMU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pGh8C+WjFDMkawFcUIWtEsUhPrhmYCi0exlZBJVzag/j57IfTMGMCHT/uSH6nBnO/ qY69xO3WOk/r1W/nY7ZPEMpmuOI6hdpqLNYRfGc4Gj51zroYfmHeyncccCPbuV3bTM 0ceZjyKGyOgzw1dXPXsNfavYYygL09hqrvNouTDMbuQ0q9pKNSiMRr9n9jo2Z1xdvb vsUql2XbzlSbef8FR2Oigx6di1bi7E53UAcfZ+7YnudmAoB5FijOwKYUnwaRJksD0w 8zAkeBSFe9ptgTiK7hq96ZWzV93WtNPGAB0vfBVLs1xXjziMbouEqxrvD9IssoC4VO 3HpR7NIvLXa8A== From: Josh Poimboeuf <jpoimboe@kernel.org> To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>, Miroslav Benes <mbenes@suse.cz> Subject: [PATCH 3/3] objtool: Generate ORC data for __pfx code Date: Wed, 12 Apr 2023 13:26:15 -0700 Message-Id: <bc3344e51f3e87102f1301a0be0f72a7689ea4a4.1681331135.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <cover.1681331135.git.jpoimboe@kernel.org> References: <cover.1681331135.git.jpoimboe@kernel.org> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763003689658234902?= X-GMAIL-MSGID: =?utf-8?q?1763003689658234902?= |
Series |
objtool: Generate ORC data for __pfx code
|
|
Commit Message
Josh Poimboeuf
April 12, 2023, 8:26 p.m. UTC
Allow unwinding from prefix code by copying the CFI from the starting
instruction of the corresponding function. Even when the NOPs are
replaced, they're still stack-invariant instructions so the same ORC
entry can be reused everywhere.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/check.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
Comments
On Wed, Apr 12, 2023 at 01:26:15PM -0700, Josh Poimboeuf wrote: > @@ -4158,7 +4172,7 @@ static int add_prefix_symbols(struct objtool_file *file) > { > struct section *sec; > struct symbol *func; > - int ret, warnings = 0; > + int warnings = 0; > > for_each_sec(file, sec) { > if (!(sec->sh.sh_flags & SHF_EXECINSTR)) Stray hunk that should go in the first patch I suppose.
On Wed, Apr 12, 2023 at 01:26:15PM -0700, Josh Poimboeuf wrote: > Allow unwinding from prefix code by copying the CFI from the starting > instruction of the corresponding function. Even when the NOPs are > replaced, they're still stack-invariant instructions so the same ORC > entry can be reused everywhere. > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> > --- > tools/objtool/check.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index 2f3136145b2e..3f27a0278bf8 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -4123,6 +4123,7 @@ static bool ignore_unreachable_insn(struct objtool_file *file, struct instructio > static int add_prefix_symbol(struct objtool_file *file, struct symbol *func) > { > struct instruction *insn, *prev; > + struct cfi_state *cfi; > > insn = find_insn(file, func->sec, func->offset); > if (!insn) > @@ -4151,6 +4152,19 @@ static int add_prefix_symbol(struct objtool_file *file, struct symbol *func) > if (!prev) > return -1; > > + if (!insn->cfi) { > + /* > + * This can happen if stack validation isn't enabled or the > + * function is annotated with STACK_FRAME_NON_STANDARD. > + */ > + return 0; > + } > + > + /* Propagate insn->cfi to the prefix code */ > + cfi = cfi_hash_find_or_add(insn->cfi); > + for (; prev != insn; prev = next_insn_same_sec(file, prev)) > + prev->cfi = cfi; > + > return 0; > } FWIW, this makes the whole thing hard rely on the prefix being single byte NOPs -- which they are, but perhaps we should assert this?
On Thu, Apr 13, 2023 at 01:24:26PM +0200, Peter Zijlstra wrote: > > + if (!insn->cfi) { > > + /* > > + * This can happen if stack validation isn't enabled or the > > + * function is annotated with STACK_FRAME_NON_STANDARD. > > + */ > > + return 0; > > + } > > + > > + /* Propagate insn->cfi to the prefix code */ > > + cfi = cfi_hash_find_or_add(insn->cfi); > > + for (; prev != insn; prev = next_insn_same_sec(file, prev)) > > + prev->cfi = cfi; > > + > > return 0; > > } > > FWIW, this makes the whole thing hard rely on the prefix being single > byte NOPs -- which they are, but perhaps we should assert this? Couldn't they be any stack-invariant instructions?
On Thu, Apr 13, 2023 at 08:29:33AM -0700, Josh Poimboeuf wrote: > On Thu, Apr 13, 2023 at 01:24:26PM +0200, Peter Zijlstra wrote: > > > + if (!insn->cfi) { > > > + /* > > > + * This can happen if stack validation isn't enabled or the > > > + * function is annotated with STACK_FRAME_NON_STANDARD. > > > + */ > > > + return 0; > > > + } > > > + > > > + /* Propagate insn->cfi to the prefix code */ > > > + cfi = cfi_hash_find_or_add(insn->cfi); > > > + for (; prev != insn; prev = next_insn_same_sec(file, prev)) > > > + prev->cfi = cfi; > > > + > > > return 0; > > > } > > > > FWIW, this makes the whole thing hard rely on the prefix being single > > byte NOPs -- which they are, but perhaps we should assert this? > > Couldn't they be any stack-invariant instructions? Hmm, I was thikning that since we don't know the size of the instructions being written, we need CFI for all offsets. But perhaps, since we do a left-match on IP, only one entry at the __pfx+0 location would work?
On Thu, Apr 13, 2023 at 09:24:49PM +0200, Peter Zijlstra wrote: > On Thu, Apr 13, 2023 at 08:29:33AM -0700, Josh Poimboeuf wrote: > > On Thu, Apr 13, 2023 at 01:24:26PM +0200, Peter Zijlstra wrote: > > > > + if (!insn->cfi) { > > > > + /* > > > > + * This can happen if stack validation isn't enabled or the > > > > + * function is annotated with STACK_FRAME_NON_STANDARD. > > > > + */ > > > > + return 0; > > > > + } > > > > + > > > > + /* Propagate insn->cfi to the prefix code */ > > > > + cfi = cfi_hash_find_or_add(insn->cfi); > > > > + for (; prev != insn; prev = next_insn_same_sec(file, prev)) > > > > + prev->cfi = cfi; > > > > + > > > > return 0; > > > > } > > > > > > FWIW, this makes the whole thing hard rely on the prefix being single > > > byte NOPs -- which they are, but perhaps we should assert this? > > > > Couldn't they be any stack-invariant instructions? > > Hmm, I was thikning that since we don't know the size of the > instructions being written, we need CFI for all offsets. But perhaps, > since we do a left-match on IP, only one entry at the __pfx+0 location > would work? Right, while in objtool (almost) every insn has insn->cfi, the actual ORC entries only get created at the boundaries of change.
diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 2f3136145b2e..3f27a0278bf8 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -4123,6 +4123,7 @@ static bool ignore_unreachable_insn(struct objtool_file *file, struct instructio static int add_prefix_symbol(struct objtool_file *file, struct symbol *func) { struct instruction *insn, *prev; + struct cfi_state *cfi; insn = find_insn(file, func->sec, func->offset); if (!insn) @@ -4151,6 +4152,19 @@ static int add_prefix_symbol(struct objtool_file *file, struct symbol *func) if (!prev) return -1; + if (!insn->cfi) { + /* + * This can happen if stack validation isn't enabled or the + * function is annotated with STACK_FRAME_NON_STANDARD. + */ + return 0; + } + + /* Propagate insn->cfi to the prefix code */ + cfi = cfi_hash_find_or_add(insn->cfi); + for (; prev != insn; prev = next_insn_same_sec(file, prev)) + prev->cfi = cfi; + return 0; } @@ -4158,7 +4172,7 @@ static int add_prefix_symbols(struct objtool_file *file) { struct section *sec; struct symbol *func; - int ret, warnings = 0; + int warnings = 0; for_each_sec(file, sec) { if (!(sec->sh.sh_flags & SHF_EXECINSTR))