Kernel-hardening Archive on lore.kernel.org
 help / color / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Marco Elver <elver@google.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Will Deacon <will@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Kees Cook <keescook@chromium.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-pci@vger.kernel.org,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>
Subject: Re: [PATCH 00/22] add support for Clang LTO
Date: Tue, 30 Jun 2020 13:30:16 -0700
Message-ID: <20200630203016.GI9247@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20200630201243.GD4817@hirez.programming.kicks-ass.net>

On Tue, Jun 30, 2020 at 10:12:43PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 30, 2020 at 09:19:31PM +0200, Marco Elver wrote:
> > I was asked for input on this, and after a few days digging through some
> > history, thought I'd comment. Hope you don't mind.
> 
> Not at all, being the one that asked :-)
> 
> > First of all, I agree with the concerns, but not because of LTO.
> > 
> > To set the stage better, and summarize the fundamental problem again:
> > we're in the unfortunate situation that no compiler today has a way to
> > _efficiently_ deal with C11's memory_order_consume
> > [https://lwn.net/Articles/588300/]. If we did, we could just use that
> > and be done with it. But, sadly, that doesn't seem possible right now --
> > compilers just say consume==acquire.
> 
> I'm not convinced C11 memory_order_consume would actually work for us,
> even if it would work. That is, given:
> 
>   https://lore.kernel.org/lkml/20150520005510.GA23559@linux.vnet.ibm.com/
> 
> only pointers can have consume, but like I pointed out, we have code
> that relies on dependent loads from integers.

I agree that C11 memory_order_consume is not normally what we want,
given that it is universally promoted to memory_order_acquire.

However, dependent loads from integers are, if anything, more difficult
to defend from the compiler than are control dependencies.  This applies
doubly to integers that are used to index two-element arrays, in which
case you are just asking the compiler to destroy your dependent loads
by converting them into control dependencies.

> > Will suggests doing the same in the
> > kernel: https://lkml.kernel.org/r/20200630173734.14057-19-will@kernel.org
> 
> PowerPC would need a similar thing, it too will not preserve causality
> for control dependecies.
> 
> > What we're most worried about right now is the existence of compiler
> > transformations that could break data dependencies by e.g. turning them
> > into control dependencies.
> 
> Correct.
> 
> > If this is a real worry, I don't think LTO is the magical feature that
> > will uncover those optimizations. If these compiler transformations are
> > real, they also exist in a normal build! 
> 
> Agreed, _however_ with the caveat that LTO could make them more common.
> 
> After all, with whole program analysis, the compiler might be able to
> more easily determine that our pointer @ptr is only ever assigned the
> values of &A, &B or &C, while without that visibility it would not be
> able to determine this.
> 
> Once it knows @ptr has a limited number of determined values, the
> conversion into control dependencies becomes much more likely.

Which would of course break dependent loads.

> > And if we are worried about them, we need to stop relying on dependent
> > load ordering across the board; or switch to -O0 for everything.
> > Clearly, we don't want either.
> 
> Agreed.
> 
> > Why do we think LTO is special?
> 
> As argued above, whole-program analysis would make it more likely. But I
> agree the fundamental problem exists independent from LTO.
> 
> > But as far as we can tell, there is no evidence of the dreaded "data
> > dependency to control dependency" conversion with LTO that isn't there
> > in non-LTO builds, if it's even there at all. Has the data to control
> > dependency conversion been encountered in the wild? If not, is the
> > resulting reaction an overreaction? If so, we need to be careful blaming
> > LTO for something that it isn't even guilty of.
> 
> It is mostly paranoia; in a large part driven by the fact that even if
> such a conversion were to be done, it could go a very long time without
> actually causing problems, and longer still for such problems to be
> traced back to such an 'optimization'.
> 
> That is, the collective hurt from debugging too many ordering issues.
> 
> > So, we are probably better off untangling LTO from the story:
> > 
> > 1. LTO or no LTO does not matter. The LTO series should not get tangled
> >    up with memory model issues.
> > 
> > 2. The memory model question and problems need to be answered and
> >    addressed separately.
> > 
> > Thoughts?
> 
> How hard would it be to creates something that analyzes a build and
> looks for all 'dependent load -> control dependency' transformations
> headed by a volatile (and/or from asm) load and issues a warning for
> them?
> 
> This would give us an indication of how valuable this transformation is
> for the kernel. I'm hoping/expecting it's vanishingly rare, but what do
> I know.
> 

This could be quite useful!

							Thanx, Paul

  reply index

Thread overview: 213+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 20:31 Sami Tolvanen
2020-06-24 20:31 ` [PATCH 01/22] objtool: use sh_info to find the base for .rela sections Sami Tolvanen
2020-06-24 20:31 ` [PATCH 02/22] kbuild: add support for Clang LTO Sami Tolvanen
2020-06-24 20:53   ` Nick Desaulniers
2020-06-24 21:29     ` Sami Tolvanen
2020-06-25  2:26   ` Nathan Chancellor
2020-06-25 16:13     ` Sami Tolvanen
2020-06-24 20:31 ` [PATCH 03/22] kbuild: lto: fix module versioning Sami Tolvanen
2020-06-24 20:31 ` [PATCH 04/22] kbuild: lto: fix recordmcount Sami Tolvanen
2020-06-24 21:27   ` Peter Zijlstra
2020-06-24 21:45     ` Sami Tolvanen
2020-06-25  7:45       ` Peter Zijlstra
2020-06-25 16:15         ` Sami Tolvanen
2020-06-25 20:02           ` [RFC][PATCH] objtool,x86_64: Replace recordmcount with objtool Peter Zijlstra
2020-06-25 20:54             ` Nick Desaulniers
2020-06-25 22:40             ` Sami Tolvanen
2020-06-26 11:29               ` Peter Zijlstra
2020-06-26 11:42                 ` Peter Zijlstra
2020-07-17 17:28                 ` Sami Tolvanen
2020-07-17 17:36                   ` Steven Rostedt
2020-07-17 17:47                     ` Sami Tolvanen
2020-07-17 18:05                       ` Steven Rostedt
2020-07-20 16:52                         ` Sami Tolvanen
2020-07-22 17:58                           ` Steven Rostedt
2020-07-22 18:07                             ` Sami Tolvanen
2020-07-22 17:55                 ` Steven Rostedt
2020-07-22 18:41                   ` Peter Zijlstra
2020-07-22 19:09                     ` Steven Rostedt
2020-07-22 20:03                       ` Sami Tolvanen
2020-07-22 23:56                       ` Peter Zijlstra
2020-07-23  0:06                         ` Steven Rostedt
2020-08-06 22:09                           ` Sami Tolvanen
2020-06-24 20:31 ` [PATCH 05/22] kbuild: lto: postpone objtool Sami Tolvanen
2020-06-24 21:19   ` Peter Zijlstra
2020-06-24 21:49     ` Sami Tolvanen
2020-06-25  7:47       ` Peter Zijlstra
2020-06-25 16:22         ` Sami Tolvanen
2020-06-25 18:33           ` Peter Zijlstra
2020-06-25 19:32             ` Sami Tolvanen
2020-06-24 20:31 ` [PATCH 06/22] kbuild: lto: limit inlining Sami Tolvanen
2020-06-24 21:20   ` Peter Zijlstra
2020-06-24 23:37     ` Sami Tolvanen
2020-06-24 20:31 ` [PATCH 07/22] kbuild: lto: merge module sections Sami Tolvanen
2020-06-24 21:01   ` Nick Desaulniers
2020-06-24 21:31     ` Sami Tolvanen
2020-06-24 20:31 ` [PATCH 08/22] kbuild: lto: remove duplicate dependencies from .mod files Sami Tolvanen
2020-06-24 21:13   ` Nick Desaulniers
2020-06-24 20:31 ` [PATCH 09/22] init: lto: ensure initcall ordering Sami Tolvanen
2020-06-25  0:58   ` kernel test robot
2020-06-25  4:19   ` kernel test robot
2020-06-24 20:31 ` [PATCH 10/22] init: lto: fix PREL32 relocations Sami Tolvanen
2020-06-24 20:31 ` [PATCH 11/22] pci: " Sami Tolvanen
2020-06-24 22:49   ` kernel test robot
2020-06-24 23:03     ` Nick Desaulniers
2020-06-24 23:21       ` Sami Tolvanen
2020-07-17 20:26   ` Bjorn Helgaas
2020-07-22 18:15     ` Sami Tolvanen
2020-06-24 20:31 ` [PATCH 12/22] modpost: lto: strip .lto from module names Sami Tolvanen
2020-06-24 22:05   ` Nick Desaulniers
2020-06-24 20:31 ` [PATCH 13/22] scripts/mod: disable LTO for empty.c Sami Tolvanen
2020-06-24 20:57   ` Nick Desaulniers
2020-06-24 20:31 ` [PATCH 14/22] efi/libstub: disable LTO Sami Tolvanen
2020-06-24 20:31 ` [PATCH 15/22] drivers/misc/lkdtm: disable LTO for rodata.o Sami Tolvanen
2020-06-24 20:31 ` [PATCH 16/22] arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY Sami Tolvanen
2020-06-24 20:31 ` [PATCH 17/22] arm64: vdso: disable LTO Sami Tolvanen
2020-06-24 20:58   ` Nick Desaulniers
2020-06-24 21:09     ` Nick Desaulniers
2020-06-24 23:51       ` Andi Kleen
2020-06-24 21:52     ` Sami Tolvanen
2020-06-24 23:05       ` Nick Desaulniers
2020-06-24 23:39         ` Sami Tolvanen
2020-06-24 20:31 ` [PATCH 18/22] arm64: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen
2020-06-24 20:31 ` [PATCH 19/22] x86, vdso: disable LTO only for vDSO Sami Tolvanen
2020-06-24 20:31 ` [PATCH 20/22] x86, ftrace: disable recordmcount for ftrace_make_nop Sami Tolvanen
2020-06-24 20:31 ` [PATCH 21/22] x86, relocs: Ignore L4_PAGE_OFFSET relocations Sami Tolvanen
2020-06-24 20:32 ` [PATCH 22/22] x86, build: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen
2020-06-24 21:15 ` [PATCH 00/22] add support for Clang LTO Peter Zijlstra
2020-06-24 21:30   ` Sami Tolvanen
2020-06-25  8:27     ` Will Deacon
2020-06-24 21:31   ` Nick Desaulniers
2020-06-25  8:03     ` Peter Zijlstra
2020-06-25  8:24       ` Peter Zijlstra
2020-06-25  8:57         ` Peter Zijlstra
2020-06-30 19:19           ` Marco Elver
2020-06-30 20:12             ` Peter Zijlstra
2020-06-30 20:30               ` Paul E. McKenney [this message]
2020-07-01  9:10                 ` Peter Zijlstra
2020-07-01 14:20                   ` David Laight
2020-07-01 16:06                     ` Paul E. McKenney
2020-07-02  9:37                       ` David Laight
2020-07-02 18:00                         ` Paul E. McKenney
2020-07-01  9:41                 ` Marco Elver
2020-07-01 10:03                   ` Will Deacon
2020-07-01 11:40                   ` Peter Zijlstra
2020-07-01 14:06                     ` Paul E. McKenney
2020-07-01 15:05                       ` Peter Zijlstra
2020-07-01 16:03                         ` Paul E. McKenney
2020-07-02  8:20                           ` Peter Zijlstra
2020-07-02 17:59                             ` Paul E. McKenney
2020-07-03 13:13                               ` Peter Zijlstra
2020-07-03 13:25                                 ` Peter Zijlstra
2020-07-03 14:51                                   ` Paul E. McKenney
2020-07-03 14:42                                 ` Paul E. McKenney
2020-07-06 16:26                                   ` Paul E. McKenney
2020-07-06 18:29                                     ` Peter Zijlstra
2020-07-06 18:39                                       ` Paul E. McKenney
2020-07-06 19:40                                         ` Peter Zijlstra
2020-07-06 23:41                                           ` Paul E. McKenney
2020-06-28 16:56 ` Masahiro Yamada
2020-06-29 23:20   ` Sami Tolvanen
2020-07-07 15:51     ` Sami Tolvanen
2020-07-07 16:05       ` Sami Tolvanen
2020-07-07 16:56         ` Jakub Kicinski
2020-07-07 17:17           ` Nick Desaulniers
2020-07-07 17:30             ` Jakub Kicinski
2020-07-11 16:32 ` Paul Menzel
2020-07-12  8:59   ` Sedat Dilek
2020-07-12 18:40     ` Nathan Chancellor
2020-07-14  9:44       ` Sedat Dilek
2020-07-14 17:54         ` Nick Desaulniers
2020-07-12 23:34   ` Sami Tolvanen
2020-07-14 12:16     ` Paul Menzel
2020-07-14 12:35       ` Sedat Dilek
2020-07-14 13:40         ` Paul Menzel
2020-09-03 20:30 ` [PATCH v2 00/28] Add " Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 01/28] x86/boot/compressed: Disable relocation relaxation Sami Tolvanen
2020-09-03 21:44     ` Kees Cook
2020-09-03 23:42       ` Arvind Sankar
2020-09-04  7:14         ` Nathan Chancellor
2020-09-03 20:30   ` [PATCH v2 02/28] x86/asm: Replace __force_order with memory clobber Sami Tolvanen
2020-09-03 21:45     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 03/28] lib/string.c: implement stpcpy Sami Tolvanen
2020-09-03 21:47     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 04/28] RAS/CEC: Fix cec_init() prototype Sami Tolvanen
2020-09-03 21:50     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 05/28] objtool: Add a pass for generating __mcount_loc Sami Tolvanen
2020-09-03 21:51     ` Kees Cook
2020-09-03 22:03       ` Sami Tolvanen
2020-09-04  9:31         ` peterz
2020-09-10 18:29           ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 06/28] objtool: Don't autodetect vmlinux.o Sami Tolvanen
2020-09-03 21:52     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 07/28] kbuild: add support for objtool mcount Sami Tolvanen
2020-09-03 21:56     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 08/28] x86, build: use " Sami Tolvanen
2020-09-03 21:58     ` Kees Cook
2020-09-03 22:11       ` Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 09/28] kbuild: add support for Clang LTO Sami Tolvanen
2020-09-03 22:08     ` Kees Cook
2020-09-08 17:02       ` Sami Tolvanen
2020-09-05 19:36     ` Masahiro Yamada
2020-09-08 17:10       ` Sami Tolvanen
2020-09-05 20:17     ` Masahiro Yamada
2020-09-08 17:14       ` Sami Tolvanen
2020-09-07 15:30     ` Masahiro Yamada
2020-09-08 17:30       ` Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 10/28] kbuild: lto: fix module versioning Sami Tolvanen
2020-09-03 22:11     ` Kees Cook
2020-09-08 18:23       ` Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 11/28] kbuild: lto: postpone objtool Sami Tolvanen
2020-09-03 22:19     ` Kees Cook
2020-09-08 20:56       ` Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 12/28] kbuild: lto: limit inlining Sami Tolvanen
2020-09-03 22:20     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 13/28] kbuild: lto: merge module sections Sami Tolvanen
2020-09-03 22:23     ` Kees Cook
2020-09-07 15:25     ` Masahiro Yamada
2020-09-08 21:07       ` Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 14/28] kbuild: lto: remove duplicate dependencies from .mod files Sami Tolvanen
2020-09-03 22:29     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 15/28] init: lto: ensure initcall ordering Sami Tolvanen
2020-09-03 22:40     ` Kees Cook
2020-09-08 21:16       ` Sami Tolvanen
2020-09-10  9:25     ` David Woodhouse
2020-09-10 15:07       ` Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 16/28] init: lto: fix PREL32 relocations Sami Tolvanen
2020-09-03 22:41     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 17/28] PCI: Fix PREL32 relocations for LTO Sami Tolvanen
2020-09-03 22:42     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 18/28] modpost: lto: strip .lto from module names Sami Tolvanen
2020-09-03 22:42     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 19/28] scripts/mod: disable LTO for empty.c Sami Tolvanen
2020-09-03 22:43     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 20/28] efi/libstub: disable LTO Sami Tolvanen
2020-09-03 22:43     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 21/28] drivers/misc/lkdtm: disable LTO for rodata.o Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 22/28] arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY Sami Tolvanen
2020-09-03 22:44     ` Kees Cook
2020-09-08 21:23       ` Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 23/28] arm64: vdso: disable LTO Sami Tolvanen
2020-09-03 22:45     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 24/28] KVM: arm64: disable LTO for the nVHE directory Sami Tolvanen
2020-09-03 22:45     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 25/28] arm64: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen
2020-09-03 22:45     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 26/28] x86, vdso: disable LTO only for vDSO Sami Tolvanen
2020-09-03 22:46     ` Kees Cook
2020-09-03 20:30   ` [PATCH v2 27/28] x86, relocs: Ignore L4_PAGE_OFFSET relocations Sami Tolvanen
2020-09-03 22:47     ` Kees Cook
2020-09-08 23:28       ` Sami Tolvanen
2020-09-03 20:30   ` [PATCH v2 28/28] x86, build: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen
2020-09-03 22:48     ` Kees Cook
2020-09-03 23:34   ` [PATCH v2 00/28] Add support for Clang LTO Kees Cook
2020-09-04  4:45     ` Nathan Chancellor
2020-09-03 23:38   ` Kees Cook
2020-09-04  7:53   ` Sedat Dilek
2020-09-04  8:55   ` peterz
2020-09-04  9:08     ` Sedat Dilek
2020-09-06  0:24   ` Masahiro Yamada
2020-09-08 23:46     ` Sami Tolvanen
2020-09-10  1:18       ` Masahiro Yamada
2020-09-10 15:17         ` Sami Tolvanen
2020-09-10 18:18         ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200630203016.GI9247@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=elver@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=samitolvanen@google.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Kernel-hardening Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernel-hardening/0 kernel-hardening/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernel-hardening kernel-hardening/ https://lore.kernel.org/kernel-hardening \
		kernel-hardening@lists.openwall.com
	public-inbox-index kernel-hardening

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.openwall.lists.kernel-hardening


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git