From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 90024ECAAD5 for ; Mon, 12 Sep 2022 10:58:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yvFsFAOaBkm80EM0f1OlpPgzjDyqtC/rHo89Eo2q06M=; b=PV4nw8u6i72Yla nwVQVuXV6MNZZInKnEjuzgj066/Zks3QB0ZplvDECIsDRPRCwmMBfgfYkPYKj7Mr49Sh1dosAQUvD pFyJx7IAPLbOKI30eW9AVQikeKsq2mCJOMXt5atSIVExjMX9bXG/YcNjFSLzRpzYbxsgps54wznKx 5Ifnlz0t8TW7vP9dJSZhYfkAewlN+Jauxq6DLCQMLowb11chtKdh8aj/poZ/5NgWfkkSzBE4aN1AM zfR13aMOChSI4PbAfmhp6xB4zPgGuneT5RVtvOPLyEL0vPFQ62/9TMzzvEhccTTc9r13OKU4PHChY MbliVxWjuiH1M7sWu3fA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXh74-0093OL-42; Mon, 12 Sep 2022 10:56:26 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXh3I-0091GE-6L for linux-arm-kernel@lists.infradead.org; Mon, 12 Sep 2022 10:52:34 +0000 Received: from nazgul.tnic (unknown [185.122.133.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 642B61EC04F0; Mon, 12 Sep 2022 12:52:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1662979941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=FgvRemfYbKJ8Gn7+wP5vaCT+FhTTeor282QL7mPb06M=; b=GAA4f6zA1Q6IHDz2IsvfdeVTJQZIyGU+2XcK84evnx9QsQFTVuUiQn8z6Hj17Tykekb7cI KGL7zUPl0vo7bMDpyNUoacP25QtdXp5YI3Ib2B7rPxYMA+YZJPmfxBdgjrD87xox95Nomk ZN+TjlNyCYIXoPN/StONY8ThF7Sv9ME= Date: Mon, 12 Sep 2022 12:52:34 +0200 From: Borislav Petkov To: Josh Poimboeuf , Michael Matz Cc: linux-toolchains@vger.kernel.org, Peter Zijlstra , Indu Bhagat , Nick Desaulniers , linux-kernel@vger.kernel.org, "Jose E. Marchesi" , Miroslav Benes , Mark Rutland , Will Deacon , x86@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Ard Biesheuvel , Chen Zhongjin , Sathvika Vasireddy , Christophe Leroy , Mark Brown Subject: Re: [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn} Message-ID: References: <20220909180704.jwwed4zhwvin7uyi@treble> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220909180704.jwwed4zhwvin7uyi@treble> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220912_035232_804233_018B69CC X-CRM114-Status: GOOD ( 28.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org + matz. Micha, any opinions on the below are appreciated. Thx. On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote: > Hi, > > Here's a preview of what I'm planning to discuss at the LPC toolchains > microconference. Feel free to start the discussion early :-) > > This is a proposal for some new minor GCC/Clang features which would > help objtool greatly. > > > Background > ---------- > > Objtool is a kernel-specific tool which reverse engineers the control > flow graph (CFG) of compiled objects. It then performs various > validations, annotations, and modifications, mostly with the goal of > improving robustness and security of the kernel. > > Objtool features which use the CFG include include: > validation/generation of unwinding metadata; validation of Intel SMAP > rules; and validation of kernel "noinstr" rules (preventing compiler > instrumentation in certain critical sections). > > In general it's not feasible for the traditional toolchain to do any of > this work, because the kernel has a lot of "blind spots" which the > toolchain doesn't have visibility to, notably asm and inline asm. > Manual .cfi annotations are very difficult to maintain and even more > difficult to ensure correctness. Also, due to kernel live patching, the > kernel relies on 100% correctness of unwinding metadata, whereas the > toolchain treats it as a best effort. > > > Challenges > ---------- > > Reverse engineering the control flow graph is mostly quite > straightforward, with two notable exceptions: > > 1) Jump tables (e.g., switch statements): > > Depending on the architecture, it's somewhere between difficult and > impossible to reliabily identify which indirect jumps correspond to > jump tables, and what are their corresponding intra-function jump > destinations. > > 2) Noreturn functions: > > There's no reliable way to determine which functions are designated > by the compiler to be noreturn (either explictly via function > attribute, or implicitly via a static function which is a wrapper > around a noreturn function.) This information is needed because the > code after the call to such a function is optimized out as > unreachable and objtool has no way of knowing that. > > > Proposal > -------- > > Add the following new compiler flags which create non-allocatable ELF > sections which "annotate" control flow: > > (Note this is purely hypothetical, intended for starting a discussion. > I'm not a compiler person and I haven't written any compiler code.) > > > 1) -fannotate-jump-table > > Create an .annotate.jump_table section which is an array of the > following variable-length structure: > > struct annotate_jump_table { > void *indirect_jmp; > long num_targets; > void *targets[]; > }; > > > For example, given the following switch statement code: > > .Lswitch_jmp: > // %rax is .Lcase_1 or .Lcase_2 > jmp %rax > > .Lcase_1: > ... > .Lcase_2: > ... > > > Add the following code: > > .pushsection .annotate.jump_table > // indirect JMP address > .quad .Lswitch_jmp > > // num jump targets > .quad 2 > > // indirect JMP target addresses > .quad .Lcase_1 > .quad .Lcase_2 > .popsection > > > 2) -fannotate-noreturn > > Create an .annotate.noreturn section which is an array of pointers to > noreturn functions (both explicit/implicit and defined/undefined). > > > For example, given the following three noreturn functions: > > // explicit noreturn: > __attribute__((__noreturn__)) void func1(void) > { > exit(1); > } > > // explicit noreturn (extern): > extern __attribute__((__noreturn__)) void func2(void); > > // implicit noreturn: > static void func3(void) > { > // call noreturn function > func2(); > } > > > Add the following code: > > .pushsection .annotate.noreturn > .quad func1 > .quad func2 > .quad func3 > .popsection > > > Alternatives > ------------ > > Another idea which has been floated in the past is for objtool to read > DWARF (or .eh_frame) to help it figure out the control flow. That > hasn't been tried yet, but would be considerably more difficult and > fragile IMO. > > > -- > Josh -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel