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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 CA374C4363A for ; Tue, 20 Oct 2020 18:52:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6163121BE5 for ; Tue, 20 Oct 2020 18:52:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KRf3NvWH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437768AbgJTSwf (ORCPT ); Tue, 20 Oct 2020 14:52:35 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:60900 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2437759AbgJTSwf (ORCPT ); Tue, 20 Oct 2020 14:52:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603219953; 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=oyUoHsRQhW9Pp4iIO9savPkdYtOE6vEjDDEEmlMww18=; b=KRf3NvWHkK2GE7nXgomITyNOOrR7WuvachroMvY5YU5nP+WSwLX8FqQ46zzbOF1EH8RNct fc/gMptPgis+R1LRcfOazl6ugjpbCXppnc+B5yHujXsvsbiQ3WvXs8QkljAyZg+le2eVBF DVqksy0pPDl8OFLG7UUS/2znGUWj/Fc= 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-213-K36-fE2_MKaUTN0-WM3Zrg-1; Tue, 20 Oct 2020 14:52:29 -0400 X-MC-Unique: K36-fE2_MKaUTN0-WM3Zrg-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 9055257050; Tue, 20 Oct 2020 18:52:26 +0000 (UTC) Received: from treble (ovpn-120-130.rdu2.redhat.com [10.10.120.130]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C7FC65B4B3; Tue, 20 Oct 2020 18:52:20 +0000 (UTC) Date: Tue, 20 Oct 2020 13:52:17 -0500 From: Josh Poimboeuf To: Sami Tolvanen Cc: Peter Zijlstra , Jann Horn , the arch/x86 maintainers , Masahiro Yamada , Steven Rostedt , Will Deacon , Greg Kroah-Hartman , "Paul E. McKenney" , Kees Cook , Nick Desaulniers , clang-built-linux , Kernel Hardening , linux-arch , Linux ARM , linux-kbuild , kernel list , linux-pci@vger.kernel.org Subject: Re: [PATCH v6 22/25] x86/asm: annotate indirect jumps Message-ID: <20201020185217.ilg6w5l7ujau2246@treble> References: <20201013003203.4168817-1-samitolvanen@google.com> <20201013003203.4168817-23-samitolvanen@google.com> <20201015102216.GB2611@hirez.programming.kicks-ass.net> <20201015203942.f3kwcohcwwa6lagd@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 Tue, Oct 20, 2020 at 09:45:06AM -0700, Sami Tolvanen wrote: > On Thu, Oct 15, 2020 at 1:39 PM Josh Poimboeuf wrote: > > > > On Thu, Oct 15, 2020 at 12:22:16PM +0200, Peter Zijlstra wrote: > > > On Thu, Oct 15, 2020 at 01:23:41AM +0200, Jann Horn wrote: > > > > > > > It would probably be good to keep LTO and non-LTO builds in sync about > > > > which files are subjected to objtool checks. So either you should be > > > > removing the OBJECT_FILES_NON_STANDARD annotations for anything that > > > > is linked into the main kernel (which would be a nice cleanup, if that > > > > is possible), > > > > > > This, I've had to do that for a number of files already for the limited > > > vmlinux.o passes we needed for noinstr validation. > > > > Getting rid of OBJECT_FILES_NON_STANDARD is indeed the end goal, though > > I'm not sure how practical that will be for some of the weirder edge > > case. > > > > On a related note, I have some old crypto cleanups which need dusting > > off. > > Building allyesconfig with this series and LTO enabled, I still see > the following objtool warnings for vmlinux.o, grouped by source file: > > arch/x86/entry/entry_64.S: > __switch_to_asm()+0x0: undefined stack state > .entry.text+0xffd: sibling call from callable instruction with > modified stack frame > .entry.text+0x48: stack state mismatch: cfa1=7-8 cfa2=-1+0 Not sure what this one's about, there's no OBJECT_FILES_NON_STANDARD? > arch/x86/entry/entry_64_compat.S: > .entry.text+0x1754: unsupported instruction in callable function > .entry.text+0x1634: redundant CLD > .entry.text+0x15fd: stack state mismatch: cfa1=7-8 cfa2=-1+0 > .entry.text+0x168c: stack state mismatch: cfa1=7-8 cfa2=-1+0 Ditto. > arch/x86/kernel/head_64.S: > .head.text+0xfb: unsupported instruction in callable function Ditto. > arch/x86/kernel/acpi/wakeup_64.S: > do_suspend_lowlevel()+0x116: sibling call from callable instruction > with modified stack frame We'll need to look at how to handle this one. > arch/x86/crypto/camellia-aesni-avx2-asm_64.S: > camellia_cbc_dec_32way()+0xb3: stack state mismatch: cfa1=7+520 cfa2=7+8 > camellia_ctr_32way()+0x1a: stack state mismatch: cfa1=7+520 cfa2=7+8 I can clean off my patches for all the crypto warnings. > arch/x86/lib/retpoline.S: > __x86_retpoline_rdi()+0x10: return with modified stack frame > __x86_retpoline_rdi()+0x0: stack state mismatch: cfa1=7+32 cfa2=7+8 > __x86_retpoline_rdi()+0x0: stack state mismatch: cfa1=7+32 cfa2=-1+0 Is this with upstream? I thought we fixed that with UNWIND_HINT_RET_OFFSET. > Josh, Peter, any thoughts on what would be the preferred way to fix > these, or how to tell objtool to ignore this code? One way or another, the patches need to be free of warnings before getting merged. I can help, though I'm traveling and only have limited bandwidth for at least the rest of the month. Ideally we'd want to have objtool understand everything, with no whitelisting, but some cases (e.g. suspend code) can be tricky. I wouldn't be opposed to embedding the whitelist in the binary, in a discardable section. It should be relatively easy, but as I mentioned I may or may not have time to work on it for a bit. I'm working half days, and now the ocean beckons from the window of my camper. -- 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 AD245C4363A for ; Tue, 20 Oct 2020 18:54:01 +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 255692222D for ; Tue, 20 Oct 2020 18:54:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Hvwh9a5T"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DtYRZ5cH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 255692222D 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=NoPU2r7U6H3gwJFwlx7vUTu0nL67KQNDAt4TJU8PPMM=; b=Hvwh9a5TGHfI3QXkD+zrR5dfu R/VH3wrufN+vhBI1VJHDwScTnUKxX9cxwkXMzidh07IaFbQL1XBX3HhfSlb2b/bhyW1QDQekD2xn5 YDW0j6L63mloSiW9YhLr3U1Xs+thY4BTdanUkigPXSBkLcnIrrTznuSlTGr+BfzPSKEt8kdujikkW /Y2sy4t/Io5Qwf7aLMK1Afx/DUodAD6hjKp2HsY4fOypvW6ztK4e1zU/WOWcWF56RXiMA0CIfrdC2 3t8r7SX6VcJejkFw7fy8MkPxksbOgM/iaKik+HcDlfyXVzFeHuRm4a+RxRF7cTiuRZj0KfOlpP8xV XmZwnfOpg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kUwkO-0005Xn-TZ; Tue, 20 Oct 2020 18:52:36 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kUwkK-0005Ws-Qq for linux-arm-kernel@lists.infradead.org; Tue, 20 Oct 2020 18:52:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603219952; 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=oyUoHsRQhW9Pp4iIO9savPkdYtOE6vEjDDEEmlMww18=; b=DtYRZ5cHqlSfahfDnvwoMnp7GkEkPAH5zbkt1jIa1wDY4wKAv0Jn4aPFPrkmwm16f1IXDA GhPaXXTkvQlEiEW3cW+h+grFLBrIUo6Rz4NVxitAgpsMarHH9lyx7UST7VEQW6+mfb0EsA ugvbZnkrL014WS9CcMLP19zXVRcoXoA= 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-213-K36-fE2_MKaUTN0-WM3Zrg-1; Tue, 20 Oct 2020 14:52:29 -0400 X-MC-Unique: K36-fE2_MKaUTN0-WM3Zrg-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 9055257050; Tue, 20 Oct 2020 18:52:26 +0000 (UTC) Received: from treble (ovpn-120-130.rdu2.redhat.com [10.10.120.130]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C7FC65B4B3; Tue, 20 Oct 2020 18:52:20 +0000 (UTC) Date: Tue, 20 Oct 2020 13:52:17 -0500 From: Josh Poimboeuf To: Sami Tolvanen Subject: Re: [PATCH v6 22/25] x86/asm: annotate indirect jumps Message-ID: <20201020185217.ilg6w5l7ujau2246@treble> References: <20201013003203.4168817-1-samitolvanen@google.com> <20201013003203.4168817-23-samitolvanen@google.com> <20201015102216.GB2611@hirez.programming.kicks-ass.net> <20201015203942.f3kwcohcwwa6lagd@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-20201020_145232_908603_EC077C74 X-CRM114-Status: GOOD ( 29.61 ) 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: linux-arch , Kees Cook , "Paul E. McKenney" , Jann Horn , Peter Zijlstra , Greg Kroah-Hartman , Masahiro Yamada , the arch/x86 maintainers , Nick Desaulniers , kernel list , Steven Rostedt , linux-kbuild , clang-built-linux , linux-pci@vger.kernel.org, Kernel Hardening , Will Deacon , Linux ARM 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 Tue, Oct 20, 2020 at 09:45:06AM -0700, Sami Tolvanen wrote: > On Thu, Oct 15, 2020 at 1:39 PM Josh Poimboeuf wrote: > > > > On Thu, Oct 15, 2020 at 12:22:16PM +0200, Peter Zijlstra wrote: > > > On Thu, Oct 15, 2020 at 01:23:41AM +0200, Jann Horn wrote: > > > > > > > It would probably be good to keep LTO and non-LTO builds in sync about > > > > which files are subjected to objtool checks. So either you should be > > > > removing the OBJECT_FILES_NON_STANDARD annotations for anything that > > > > is linked into the main kernel (which would be a nice cleanup, if that > > > > is possible), > > > > > > This, I've had to do that for a number of files already for the limited > > > vmlinux.o passes we needed for noinstr validation. > > > > Getting rid of OBJECT_FILES_NON_STANDARD is indeed the end goal, though > > I'm not sure how practical that will be for some of the weirder edge > > case. > > > > On a related note, I have some old crypto cleanups which need dusting > > off. > > Building allyesconfig with this series and LTO enabled, I still see > the following objtool warnings for vmlinux.o, grouped by source file: > > arch/x86/entry/entry_64.S: > __switch_to_asm()+0x0: undefined stack state > .entry.text+0xffd: sibling call from callable instruction with > modified stack frame > .entry.text+0x48: stack state mismatch: cfa1=7-8 cfa2=-1+0 Not sure what this one's about, there's no OBJECT_FILES_NON_STANDARD? > arch/x86/entry/entry_64_compat.S: > .entry.text+0x1754: unsupported instruction in callable function > .entry.text+0x1634: redundant CLD > .entry.text+0x15fd: stack state mismatch: cfa1=7-8 cfa2=-1+0 > .entry.text+0x168c: stack state mismatch: cfa1=7-8 cfa2=-1+0 Ditto. > arch/x86/kernel/head_64.S: > .head.text+0xfb: unsupported instruction in callable function Ditto. > arch/x86/kernel/acpi/wakeup_64.S: > do_suspend_lowlevel()+0x116: sibling call from callable instruction > with modified stack frame We'll need to look at how to handle this one. > arch/x86/crypto/camellia-aesni-avx2-asm_64.S: > camellia_cbc_dec_32way()+0xb3: stack state mismatch: cfa1=7+520 cfa2=7+8 > camellia_ctr_32way()+0x1a: stack state mismatch: cfa1=7+520 cfa2=7+8 I can clean off my patches for all the crypto warnings. > arch/x86/lib/retpoline.S: > __x86_retpoline_rdi()+0x10: return with modified stack frame > __x86_retpoline_rdi()+0x0: stack state mismatch: cfa1=7+32 cfa2=7+8 > __x86_retpoline_rdi()+0x0: stack state mismatch: cfa1=7+32 cfa2=-1+0 Is this with upstream? I thought we fixed that with UNWIND_HINT_RET_OFFSET. > Josh, Peter, any thoughts on what would be the preferred way to fix > these, or how to tell objtool to ignore this code? One way or another, the patches need to be free of warnings before getting merged. I can help, though I'm traveling and only have limited bandwidth for at least the rest of the month. Ideally we'd want to have objtool understand everything, with no whitelisting, but some cases (e.g. suspend code) can be tricky. I wouldn't be opposed to embedding the whitelist in the binary, in a discardable section. It should be relatively easy, but as I mentioned I may or may not have time to work on it for a bit. I'm working half days, and now the ocean beckons from the window of my camper. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel