Message ID | 20230716184204.GFZLQ5/DJ1+q8vpuuN@fat_crate.local |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp735242vqt; Sun, 16 Jul 2023 11:51:13 -0700 (PDT) X-Google-Smtp-Source: APBJJlHG7mSSFWuA3rlo2ltzcRE3nkEBK5G4M5qmmdU4X6UBax3FWwAWt4dsVW5dtS/r2rb4Zqn0 X-Received: by 2002:a17:907:4c5:b0:988:d6ca:ea72 with SMTP id vz5-20020a17090704c500b00988d6caea72mr8641869ejb.71.1689533473166; Sun, 16 Jul 2023 11:51:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689533473; cv=none; d=google.com; s=arc-20160816; b=unZrrPgUAz4TTS2W6llJdJMhNieUCOYFXJc4XWbvumRjO/3g4yu/zc8DeSyuk8W/JP erczjmi5EVZSP2fOCBDcij+0ezIwNsMZMr7llQnpQeNqU9BBjdRpCxtyMIF3EzZ9bMdv sDrJd0YigUq+cUqmZcdlaUgRwXy31TWIcy4DR36HZQXMvfxvrAhBNG8k4wSaVFJqDc4V IcHjTTP0IqSCfMRK4ddVnZyYB4m14oitNUCfGdI8IUI0yMbpWKW+G1IQApybOqUonyO/ d+GF0E2KHSBIn/IjqftgufiOqs3ssTVGnjBnXvUU5GktZWsuIEfBh7kRH1biSTEdmAum OLfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date:dkim-signature:dkim-signature; bh=GxGezcAwkBcGtUwyX+J8v7tcHhZV47pZ7EUlmh0zRns=; fh=4/FIPFqCYmHycGU950iZ4KizC+V08kPqoC9gPoU/Jm8=; b=S6tut/C8TjUtgvulDTpcxNVLyIkQNehgYoUZBAZi7dvDG+r5WodJrNpVeRApfPNElZ mzEFqcO8kckxJIxHXTvh/C8+3yBlULT08SyVfHWJ6Ib6yIJrLhTjE7z0tVIsybz80YoJ DpwmXT8PLZV+6NhTVw1QVDpG5EpVeyhtfMSsUvzueodhFd+oc8phTdNVlLhkMJQlKJcF sH7LxpROJXZYxOa/dp98eI1SM0BlaWy5Dgd3yoDe2jcpNvi/9P7vl3uPimiwt6KYJ23z pp2PY9IdT13Zs0q+p8G2JFc2blCmFCyCd27TiB5lKEHzU52StqWWN0Rik1z4CStHyjf/ Y65w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=F8j1ZJUh; dkim=pass header.i=@alien8.de header.s=alien8 header.b=dRu7xOZ5; 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=alien8.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kl10-20020a170907994a00b00992b8854f48si13085795ejc.556.2023.07.16.11.50.49; Sun, 16 Jul 2023 11:51:13 -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=@alien8.de header.s=dkim header.b=F8j1ZJUh; dkim=pass header.i=@alien8.de header.s=alien8 header.b=dRu7xOZ5; 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=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229986AbjGPSmO (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Sun, 16 Jul 2023 14:42:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229503AbjGPSmN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 16 Jul 2023 14:42:13 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77029116 for <linux-kernel@vger.kernel.org>; Sun, 16 Jul 2023 11:42:12 -0700 (PDT) Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) (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 2486E1EC096C; Sun, 16 Jul 2023 20:42:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1689532931; 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:references; bh=GxGezcAwkBcGtUwyX+J8v7tcHhZV47pZ7EUlmh0zRns=; b=F8j1ZJUhTdfWLVST64hzEpk498a97DOBXNoaGkvD1V/qAzSueZF2Lxd81JcjHZrYFIyb6z 6ww1mmRNHInqjNLTVqKb5nlkDDmf9qRRmZ7o4R6ZJZDLrYWEyzxYynIg1Dgln+8mHsay9Q LVFqQFVIgZVhgBWi2ff6uPfQ1OoY1+M= X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0bR7prrroyNn; Sun, 16 Jul 2023 18:42:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1689532928; bh=GxGezcAwkBcGtUwyX+J8v7tcHhZV47pZ7EUlmh0zRns=; h=Date:From:To:Cc:Subject:From; b=dRu7xOZ5olELO/yRSIVQr9GqSMJ9BiM+63KdtEt7aAaYSlB5IFAqDd6zoJb1s2fmb jKI+R5ZdNY+9JMOLVneY4QFf+7fYkWnflHTIhkP2bU7laRvaUQteJW8WNoZr4jAC4/ dCbLn7hxoOqZO3+oC20S96Zo2wB1lOYE/VL/na96PnOJ3XmIuFkXUqp3Kt4UB4/rtl FChaV71l7ayvU/OZMRCHIxueZm/M6CRSuW1sMNnH9slHkUy+cioOEHyu8h9owY1a6T m+N2yHUE2FSSEeWSusqnV4BaRpsM6H30wZdyla1UfrbGomWYGJGlrXUuErINcEgeac Uozv0fkVVj9jA1Sq/IrT3p5VWV3ARus25yowqgpAS036cxEQsywX7Wob5mmQlZIdcb 9zr/1PyCKQ4xaSjJKIC9qaUNQvm7ZMx97rN65fdVF5K5zJlCWfLJoh/iZHBhbjiWQ1 2aQDk5sY7pGJuxinLRyUo2b4bgDr8w1qPY85qzoSOvpfdRAVDt6s96G+yNF4gYmt2y Ay7shiSU8CsVr+cMc1nQIOn9QJaltu1XDj5JZ+oGrvBWxwZJPP4+smx9a8+7iNjFS/ IcGdJ13ma7nG1TntSTMbhRmzY2x1X+LFEcQ0ebNYbUwJwhi6X7firphsiQGhA1VoaU k7TmIFfqewM5zkP0y8DfLAmY= Received: from zn.tnic (pd9530d32.dip0.t-ipconnect.de [217.83.13.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 860C440E00F4; Sun, 16 Jul 2023 18:42:05 +0000 (UTC) Date: Sun, 16 Jul 2023 20:42:04 +0200 From: Borislav Petkov <bp@alien8.de> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org> Subject: [GIT PULL] objtool/urgent for v6.5-rc2 Message-ID: <20230716184204.GFZLQ5/DJ1+q8vpuuN@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: INBOX X-GMAIL-THRID: 1771604251229655739 X-GMAIL-MSGID: 1771604251229655739 |
Series |
[GIT,PULL] objtool/urgent for v6.5-rc2
|
|
Pull-request
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/objtool_urgent_for_v6.5_rc2Message
Borislav Petkov
July 16, 2023, 6:42 p.m. UTC
Hi Linus, please pull two urgent objtool fixes for 6.5. Thx. --- The following changes since commit 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5: Linux 6.5-rc1 (2023-07-09 13:53:13 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/objtool_urgent_for_v6.5_rc2 for you to fetch changes up to 719a937b7003933de1298ffa4b881dd6a234e244: iov_iter: Mark copy_iovec_from_user() noclone (2023-07-10 09:52:28 +0200) ---------------------------------------------------------------- - Mark copy_iovec_from_user() __noclone in order to prevent gcc from doing an inter-procedural optimization and confuse objtool - Initialize struct elf fully to avoid build failures ---------------------------------------------------------------- Michal Kubecek (1): objtool: initialize all of struct elf Peter Zijlstra (1): iov_iter: Mark copy_iovec_from_user() noclone lib/iov_iter.c | 2 +- tools/objtool/elf.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Comments
On Sun, 16 Jul 2023 at 11:42, Borislav Petkov <bp@alien8.de> wrote: > > - Mark copy_iovec_from_user() __noclone in order to prevent gcc from > doing an inter-procedural optimization and confuse objtool This is painful. Isn't there some way to mark the user_access_begin() itself so that the compiler doesn't move it? I've pulled this thing, but it does seem like we're chasing the symptoms, not the deeper cause.. Linus
The pull request you sent on Sun, 16 Jul 2023 20:42:04 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/objtool_urgent_for_v6.5_rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8a3e4a64849eb9da0e8c7e693978499562581631
Thank you!
On 7/16/23 22:39, Linus Torvalds wrote: > On Sun, 16 Jul 2023 at 11:42, Borislav Petkov <bp@alien8.de> wrote: >> >> - Mark copy_iovec_from_user() __noclone in order to prevent gcc from >> doing an inter-procedural optimization and confuse objtool > > This is painful. > > Isn't there some way to mark the user_access_begin() itself so that > the compiler doesn't move it? > > I've pulled this thing, but it does seem like we're chasing the > symptoms, not the deeper cause.. The deeper cause is that the [code generated by the] user_access_begin() and user_write_access_end()/unsafe_get_user() calls end up in different functions and objtool doesn't like that. If you are willing to add another helper function that also takes the label argument, you could do something like this: #define user_access_begin_label(a,b, err_label) \ ({ \ asm_volatile_goto("" :::: err_label); \ user_access_begin(a,b); \ }) The asm_volatile_goto() isn't a real goto (it emits no instructions), but it makes GCC believe there's a potential jump there and prevents the compiler from splitting up the function across the label and its usage. unsafe_get_user() already takes this same label as an argument and the user_access_end() call is where the label is defined. I tried first to avoid changing the uaccess API by defining a fixed label inside user_write_access_end() and always doing "fake jumps" to this fixed label from both user_write_access_begin() and unsafe_get_user(). However, you run into trouble with functions like sys_waitid() in kernel/exit.c that have multiple user_write_access_end() calls. You might think that you could switch them around -- define the label in _begin() and fake-jump to it from _end(), but that doesn't work either since _begin() needs to be an expression and labels defined inside a statement expression are not accessible outside that expression... Anyway, attached a proof of concept patch that fixes the objtool warning, but I didn't even do a full build test. Vegard
On Tue, 18 Jul 2023 at 04:02, Vegard Nossum <vegard.nossum@oracle.com> wrote: > > If you are willing to add another helper function that also takes the > label argument, you could do something like this: Ugh. That's a bit uglier than I was hoping for. I was hoping more like "use this special attribute to mark this asm as being something that cannot be moved across function boundaries". Now a "we have to make up horrible games and pass in labels that are not used and use a completely different API". Oh well. I guess in the end we can just continue to work around this. After all, in many ways this isn't about the code - the AC setting and clearing is fine - it's about objtool not doing the analysis across function boundaries. I guess we could have just marked these iovec copy functions "always_inline" too, and avoided it that way. Linus