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.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,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 EF8CBC4363A for ; Tue, 20 Oct 2020 19:26: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 5ABB922251 for ; Tue, 20 Oct 2020 19:26:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="d6xqJ6L6"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="MD9d7uz3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5ABB922251 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DsbuHIyHHpfhaegsorM+7nXE9xNhGaGsV+OZBNjUA14=; b=d6xqJ6L6VsxwYK8zHmnbe2eOB W0Z/Id++5rC4N30vKgMCrxNKKqrb0m3tKSz7zPsTApP6dcNUsXKMXRkC7v4tKjuF7FrJpYl0gxLnU 5FEygVmn622wJFhZd/SVQZFwoLjMB798gId+W0MX5FtwBtU1nHUBop28X2DwsLsbjrsBgTfS/W/x9 d0a7sJxcNAa9YmkQzdsEtB5RI5FX5CjBHBMVKRlq/Kwlwz0TPC5agPyHSa3u70uMhAXBMITm5jMcG O62N4geENb++eGrCmE5FXtHXpOtPuLwFrW6vctk48OWAHQwfLZ/dsJI56HfpjkWevr1XNavEbZvjb KGTa556nA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kUxFf-0007a2-Bw; Tue, 20 Oct 2020 19:24:56 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kUxFa-0007Yx-BW for linux-arm-kernel@lists.infradead.org; Tue, 20 Oct 2020 19:24:51 +0000 Received: by mail-ed1-x542.google.com with SMTP id 33so3012614edq.13 for ; Tue, 20 Oct 2020 12:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0aSlO1W7vXD8wpvCCG7wGbAKM67BTQt/FrRx6zZmumc=; b=MD9d7uz3cpra2FJBi9y1hEvF1r4hdy805N/H3qRtjanKJvvmB1oAnplnX1pvJFGw3p u2TpNcRLfU2Z2DTbjohMDHA66MV8G90XBOBS8mILuZVE2Tl1fio+VP73xYJigeFrlIeI thKNSd2wLZ0ZiU7v9+mZ7gKsBuhfO3C5IZPR0QUG037jFS7rG71K9DGNZPifpYw5Zb3j jS/9m7X8sU7ej/VKCctxs5ZOZrMHQSjQz9JjI68haEWvlWCeAR9lPPGbS1DsHCzFD131 9coer59bAU/KEvj4fQv6K3nmuab06BfEXpdrDvwZLwzkJFQzfVDZxEo6uSKYeFUMVvag pqMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0aSlO1W7vXD8wpvCCG7wGbAKM67BTQt/FrRx6zZmumc=; b=nJJqns9ayYPuOCT9XegruH83EUqheAlNUg+PpGriIfXjVXVbyjxGiyMacC6E6ufWmj nMRhg/ZExtfo70hgbi5GXCuaO0h6GI9m5YIoezdR6KFUM6ci1Mr5VDbbIt4zts7RTSfy HyumQ5IYBTlkiC0jo1gSvIfEBbC/RO9NizZPBuxK+bJRoTE+s3s3jgvsG+iw0eLJEEsW 8AiDbCtkWHPX9gabnFEbG5gwo/aBOEjxoBoiuYRvVwrfUxX6rZck2hDQxOjcKQZ/4rMu 5edHM+bGlqS6aVYFWGSrSbvAm9L+8Mz/e7FXMsX79AxZ1JJYEsbiE/44Mbexgp8wHZQW NKVg== X-Gm-Message-State: AOAM533qapMdPRMBSIZNiCRm5prrVjEvZ+k3dfdi+FmIkJXcf26ARGtO EItDEuDIooTGKHA3zfK104onCJSS6BlEf4IFpdFVqQ== X-Google-Smtp-Source: ABdhPJyMOA23NnvKtSjkOLGiry9VkOkNifOIW4sa6w2YiQX+XkJh8M/nVDkTK78UH1bOaHTG4GNJ1uOJcZ3dDNt12gE= X-Received: by 2002:a50:88e5:: with SMTP id d92mr4494054edd.145.1603221888446; Tue, 20 Oct 2020 12:24:48 -0700 (PDT) MIME-Version: 1.0 References: <20201013003203.4168817-1-samitolvanen@google.com> <20201013003203.4168817-23-samitolvanen@google.com> <20201015102216.GB2611@hirez.programming.kicks-ass.net> <20201015203942.f3kwcohcwwa6lagd@treble> <20201020185217.ilg6w5l7ujau2246@treble> In-Reply-To: <20201020185217.ilg6w5l7ujau2246@treble> From: Sami Tolvanen Date: Tue, 20 Oct 2020 12:24:37 -0700 Message-ID: Subject: Re: [PATCH v6 22/25] x86/asm: annotate indirect jumps To: Josh Poimboeuf X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201020_152450_623208_00C6AE25 X-CRM114-Status: GOOD ( 32.97 ) 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 11:52 AM Josh Poimboeuf wrote: > > 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? Correct, because with LTO, we won't have an ELF binary to process until we compile everything into vmlinux.o, and at that point we can no longer skip individual object files. The sibling call warning is in swapgs_restore_regs_and_return_to_usermode and the stack state mismatch in entry_SYSCALL_64_after_hwframe. > > arch/x86/entry/entry_64_compat.S: > > .entry.text+0x1754: unsupported instruction in callable function This comes from a sysretl instruction in entry_SYSCALL_compat. > > .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. These are all from entry_SYSENTER_compat_after_hwframe. > > arch/x86/kernel/head_64.S: > > .head.text+0xfb: unsupported instruction in callable function > > Ditto. This is lretq in secondary_startup_64_no_verify. > > 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. Great, sounds good. > > 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. Yes, and the UNWIND_HINT_RET_OFFSET is there. > > 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. Something similar to STACK_FRAME_NON_STANDARD()? Using that seems to result in "BUG: why am I validating an ignored function?" warnings, so I suspect some additional changes are needed. Sami _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel