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 X-Spam-Level: X-Spam-Status: No, score=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C67CDC433E0 for ; Mon, 1 Feb 2021 21:46:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 803A064DC3 for ; Mon, 1 Feb 2021 21:46:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229636AbhBAVqE (ORCPT ); Mon, 1 Feb 2021 16:46:04 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:50849 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229514AbhBAVqC (ORCPT ); Mon, 1 Feb 2021 16:46:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612215875; 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: in-reply-to:in-reply-to:references:references; bh=MSmYYJUxjx/txjv3Ym8eyrnxTI/eSH9db57IFYwcwok=; b=ZHjf6r0okTKGJE+rd8C5s3NRksNjGxpWh69K9LpVENXe1C8EbwfN9z25zRjCprNJy8HqVL A8jF/8GujXq4ddA1U3nTZGhxeX+KS8kqdRQN1abKr+w2lvoSQz87yhGy/TI9ukbLKyd0PQ BOD/JJGTQsjMUe0IkVumxcd3CQeik6E= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-38-WO1Z_rXeMVGapiLOI2ZcNQ-1; Mon, 01 Feb 2021 16:44:30 -0500 X-MC-Unique: WO1Z_rXeMVGapiLOI2ZcNQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4F5401005513; Mon, 1 Feb 2021 21:44:28 +0000 (UTC) Received: from treble (ovpn-120-118.rdu2.redhat.com [10.10.120.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0341739A50; Mon, 1 Feb 2021 21:44:24 +0000 (UTC) Date: Mon, 1 Feb 2021 15:44:23 -0600 From: Josh Poimboeuf To: Nick Desaulniers Cc: Julien Thierry , Ard Biesheuvel , Mark Brown , Catalin Marinas , Kees Cook , Linux ARM , linux-efi , linux-hardening@vger.kernel.org, LKML , Mark Rutland , Masahiro Yamada , Michal Marek , Peter Zijlstra , raphael.gault@arm.com, Will Deacon , clang-built-linux Subject: Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 Message-ID: <20210201214423.dhsma73k7ccscovm@treble> References: <20210120173800.1660730-13-jthierry@redhat.com> <20210127221557.1119744-1-ndesaulniers@google.com> <20210127232651.rj3mo7c2oqh4ytsr@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: > On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf wrote: > > > > On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > > > From: Raphael Gault > > > > > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > > > detects switch-tables that are to be outputed in the ELF and writes > > > > information in an ".discard.switch_table_info" section which will be > > > > used by objtool. > > > > > > > > Signed-off-by: Raphael Gault > > > > [J.T.: Change section name to store switch table information, > > > > Make plugin Kconfig be selected rather than opt-in by user, > > > > Add a relocation in the switch_table_info that points to > > > > the jump operation itself] > > > > Signed-off-by: Julien Thierry > > > > > > Rather than tightly couple this feature to a particular toolchain via > > > plugin, it might be nice to consider what features could be spec'ed out > > > for toolchains to implement (perhaps via a -f flag). > > > > The problem is being able to detect switch statement jump table vectors. > > > > For a given indirect branch (due to a switch statement), what are all > > the corresponding jump targets? > > > > We would need the compiler to annotate that information somehow. > > Makes sense, the compiler should have this information. How is this > problem solved on x86? Thus far we've been able to successfully reverse engineer it on x86, though it hasn't been easy. There were some particulars for arm64 which made doing so impossible. (I don't remember the details.) > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > > is. > > > > Would a Clang plugin be out of the question? > > Generally, we frown on out of tree kernel modules for a couple reasons. > > Maintaining ABI compatibility when the core kernel changes is > generally not instantaneous; someone has to notice the ABI has changed > which will be more delayed than if the module was in tree. Worse is > when semantics subtly change. While we must not break userspace, we > provide no such guarantees within the kernel proper. > > Also, it's less likely that out of tree kernel modules have been > reviewed by kernel developers. They may not have the same quality, > use the recommended interfaces, follow coding conventions, etc.. > > Oh, did I say "out of tree kernel modules?" I meant "compiler > plugins." But it's two different sides of the same coin to me. I thought Android already relied on OOT modules. GCC plugins generally enforce the exact same GCC version for OOT modules. So there's no ABI to worry about. I assume Clang does the same? Or did I miss your point? > FWIW, I think the approach taken by -mstack-protector-guard-reg= is a > useful case study. It was prototyped as a GCC extension, then added > to GCC proper, then added to LLVM (currently only x86, but most of the > machinery is in place in the compiler to get it running on arm64). My > recommendation is to skip the plugin part and work on a standard > interface for compilers to implement, with input from compiler > developers. I like the idea. Is there a recommended forum for such discussions? Just an email to GCC/Clang development lists? -- Josh 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 X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48CD6C433E0 for ; Mon, 1 Feb 2021 21:45:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C9A2564D87 for ; Mon, 1 Feb 2021 21:45:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9A2564D87 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=iNFApz4YEeEpFHSuoJuTd90etT/wPijMeYGxvDZqd64=; b=kStsnd+GLIhPx9WL4+96BbtNi uxw8l7JWF7Zww4qcprPYtsIxJ7ii1ZFpQB6+DjLQQID7I/Mu/8SHFxBMGVPjdm6YOp2ouIbNOeoGf AuTTp1zMQjz8yuFcwtTuImzQhPehQ/1TjP4LmhE27ehF5Ea3FY8/0yB0eCZw4gupWnGTQftWKgNvg qedXWFqRMBut0wmKOfb8sLz0HlNSswCinCI/fMG3FfW5aOSC+OTnxl8mhn7tXAZ5FN+ydaiJQT+s2 Rp1xum5Las4X04Dt3Va9/5P0CpaJ9pCFi+OFbVUultXAtH0lw4GvxcbB74UjfNA+gLivIIZgaIRI8 5HFEQrSYg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6gzv-0004NK-Cw; Mon, 01 Feb 2021 21:44:39 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6gzs-0004MU-Ab for linux-arm-kernel@lists.infradead.org; Mon, 01 Feb 2021 21:44:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612215875; 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: in-reply-to:in-reply-to:references:references; bh=MSmYYJUxjx/txjv3Ym8eyrnxTI/eSH9db57IFYwcwok=; b=ZHjf6r0okTKGJE+rd8C5s3NRksNjGxpWh69K9LpVENXe1C8EbwfN9z25zRjCprNJy8HqVL A8jF/8GujXq4ddA1U3nTZGhxeX+KS8kqdRQN1abKr+w2lvoSQz87yhGy/TI9ukbLKyd0PQ BOD/JJGTQsjMUe0IkVumxcd3CQeik6E= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-38-WO1Z_rXeMVGapiLOI2ZcNQ-1; Mon, 01 Feb 2021 16:44:30 -0500 X-MC-Unique: WO1Z_rXeMVGapiLOI2ZcNQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4F5401005513; Mon, 1 Feb 2021 21:44:28 +0000 (UTC) Received: from treble (ovpn-120-118.rdu2.redhat.com [10.10.120.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0341739A50; Mon, 1 Feb 2021 21:44:24 +0000 (UTC) Date: Mon, 1 Feb 2021 15:44:23 -0600 From: Josh Poimboeuf To: Nick Desaulniers Subject: Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 Message-ID: <20210201214423.dhsma73k7ccscovm@treble> References: <20210120173800.1660730-13-jthierry@redhat.com> <20210127221557.1119744-1-ndesaulniers@google.com> <20210127232651.rj3mo7c2oqh4ytsr@treble> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210201_164436_529931_B7CF139E X-CRM114-Status: GOOD ( 32.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , linux-efi , Julien Thierry , clang-built-linux , Peter Zijlstra , Catalin Marinas , Masahiro Yamada , LKML , Michal Marek , raphael.gault@arm.com, Mark Brown , linux-hardening@vger.kernel.org, Will Deacon , Ard Biesheuvel , Linux ARM , Kees Cook 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 On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: > On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf wrote: > > > > On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > > > From: Raphael Gault > > > > > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > > > detects switch-tables that are to be outputed in the ELF and writes > > > > information in an ".discard.switch_table_info" section which will be > > > > used by objtool. > > > > > > > > Signed-off-by: Raphael Gault > > > > [J.T.: Change section name to store switch table information, > > > > Make plugin Kconfig be selected rather than opt-in by user, > > > > Add a relocation in the switch_table_info that points to > > > > the jump operation itself] > > > > Signed-off-by: Julien Thierry > > > > > > Rather than tightly couple this feature to a particular toolchain via > > > plugin, it might be nice to consider what features could be spec'ed out > > > for toolchains to implement (perhaps via a -f flag). > > > > The problem is being able to detect switch statement jump table vectors. > > > > For a given indirect branch (due to a switch statement), what are all > > the corresponding jump targets? > > > > We would need the compiler to annotate that information somehow. > > Makes sense, the compiler should have this information. How is this > problem solved on x86? Thus far we've been able to successfully reverse engineer it on x86, though it hasn't been easy. There were some particulars for arm64 which made doing so impossible. (I don't remember the details.) > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > > is. > > > > Would a Clang plugin be out of the question? > > Generally, we frown on out of tree kernel modules for a couple reasons. > > Maintaining ABI compatibility when the core kernel changes is > generally not instantaneous; someone has to notice the ABI has changed > which will be more delayed than if the module was in tree. Worse is > when semantics subtly change. While we must not break userspace, we > provide no such guarantees within the kernel proper. > > Also, it's less likely that out of tree kernel modules have been > reviewed by kernel developers. They may not have the same quality, > use the recommended interfaces, follow coding conventions, etc.. > > Oh, did I say "out of tree kernel modules?" I meant "compiler > plugins." But it's two different sides of the same coin to me. I thought Android already relied on OOT modules. GCC plugins generally enforce the exact same GCC version for OOT modules. So there's no ABI to worry about. I assume Clang does the same? Or did I miss your point? > FWIW, I think the approach taken by -mstack-protector-guard-reg= is a > useful case study. It was prototyped as a GCC extension, then added > to GCC proper, then added to LLVM (currently only x86, but most of the > machinery is in place in the compiler to get it running on arm64). My > recommendation is to skip the plugin part and work on a standard > interface for compilers to implement, with input from compiler > developers. I like the idea. Is there a recommended forum for such discussions? Just an email to GCC/Clang development lists? -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel