From: Thomas Garnier <thgarnie@google.com>
To: Daniel Micay <danielmicay@gmail.com>
Cc: "Ingo Molnar" <mingo@kernel.org>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H . Peter Anvin" <hpa@zytor.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Josh Poimboeuf" <jpoimboe@redhat.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Matthias Kaehlcke" <mka@chromium.org>,
"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
"Juergen Gross" <jgross@suse.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Joerg Roedel" <joro@8bytes.org>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Borislav Petkov" <bp@suse.de>, "Brian Gerst" <brgerst@gmail.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
"Len Brown" <len.brown@intel.com>, "Pavel Machek" <pavel@ucw.cz>
Subject: Re: x86: PIE support and option to extend KASLR randomization
Date: Tue, 15 Aug 2017 07:58:47 -0700 [thread overview]
Message-ID: <CAJcbSZHJ_Jy=dr4Pc3-o_Bz340cLRgu79Up5iWptwaiObwN3Hw@mail.gmail.com> (raw)
In-Reply-To: <CA+DvKQLM-a-0z985o6NQtfLtxC-K_KSkns4MyfdMUmrq7Kbtjw@mail.gmail.com>
On Tue, Aug 15, 2017 at 7:47 AM, Daniel Micay <danielmicay@gmail.com> wrote:
> On 15 August 2017 at 10:20, Thomas Garnier <thgarnie@google.com> wrote:
>> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> * Thomas Garnier <thgarnie@google.com> wrote:
>>>
>>>> > Do these changes get us closer to being able to build the kernel as truly
>>>> > position independent, i.e. to place it anywhere in the valid x86-64 address
>>>> > space? Or any other advantages?
>>>>
>>>> Yes, PIE allows us to put the kernel anywhere in memory. It will allow us to
>>>> have a full randomized address space where position and order of sections are
>>>> completely random. There is still some work to get there but being able to build
>>>> a PIE kernel is a significant step.
>>>
>>> So I _really_ dislike the whole PIE approach, because of the huge slowdown:
>>>
>>> +config RANDOMIZE_BASE_LARGE
>>> + bool "Increase the randomization range of the kernel image"
>>> + depends on X86_64 && RANDOMIZE_BASE
>>> + select X86_PIE
>>> + select X86_MODULE_PLTS if MODULES
>>> + default n
>>> + ---help---
>>> + Build the kernel as a Position Independent Executable (PIE) and
>>> + increase the available randomization range from 1GB to 3GB.
>>> +
>>> + This option impacts performance on kernel CPU intensive workloads up
>>> + to 10% due to PIE generated code. Impact on user-mode processes and
>>> + typical usage would be significantly less (0.50% when you build the
>>> + kernel).
>>> +
>>> + The kernel and modules will generate slightly more assembly (1 to 2%
>>> + increase on the .text sections). The vmlinux binary will be
>>> + significantly smaller due to less relocations.
>>>
>>> To put 10% kernel overhead into perspective: enabling this option wipes out about
>>> 5-10 years worth of painstaking optimizations we've done to keep the kernel fast
>>> ... (!!)
>>
>> Note that 10% is the high-bound of a CPU intensive workload.
>
> The cost can be reduced by using -fno-plt these days but some work
> might be required to make that work with the kernel.
>
> Where does that 10% estimate in the kernel config docs come from? I'd
> be surprised if it really cost that much on x86_64. That's a realistic
> cost for i386 with modern GCC (it used to be worse) but I'd expect
> x86_64 to be closer to 2% even for CPU intensive workloads. It should
> be very close to zero with -fno-plt.
I got 8 to 10% on hackbench. Other benchmarks were 4% or lower.
I will do look at more recent compiler and no-plt as well.
--
Thomas
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Garnier <thgarnie@google.com>
To: Daniel Micay <danielmicay@gmail.com>
Cc: "Ingo Molnar" <mingo@kernel.org>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H . Peter Anvin" <hpa@zytor.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Josh Poimboeuf" <jpoimboe@redhat.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Matthias Kaehlcke" <mka@chromium.org>,
"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
"Juergen Gross" <jgross@suse.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Joerg Roedel" <joro@8bytes.org>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Borislav Petkov" <bp@suse.de>, "Brian Gerst" <brgerst@gmail.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
"Len Brown" <len.brown@intel.com>, "Pavel Machek" <pavel@ucw.cz>,
"Tejun Heo" <tj@kernel.org>, "Christoph Lameter" <cl@linux.com>,
"Paul Gortmaker" <paul.gortmaker@windriver.com>,
"Chris Metcalf" <cmetcalf@mellanox.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
"Nicolas Pitre" <nicolas.pitre@linaro.org>,
"Christopher Li" <sparse@chrisli.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
"Lukas Wunner" <lukas@wunner.de>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Dou Liyang" <douly.fnst@cn.fujitsu.com>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Alexei Starovoitov" <ast@kernel.org>,
"Masahiro Yamada" <yamada.masahiro@socionext.com>,
"Markus Trippelsdorf" <markus@trippelsdorf.de>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Kees Cook" <keescook@chromium.org>,
"Rik van Riel" <riel@redhat.com>,
"David Howells" <dhowells@redhat.com>,
"Waiman Long" <longman@redhat.com>, "Kyle Huey" <me@kylehuey.com>,
"Peter Foley" <pefoley2@pefoley.com>,
"Tim Chen" <tim.c.chen@linux.intel.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
"Michal Hocko" <mhocko@suse.com>,
"Matthew Wilcox" <mawilcox@microsoft.com>,
"H . J . Lu" <hjl.tools@gmail.com>,
"Paul Bolle" <pebolle@tiscali.nl>,
"Rob Landley" <rob@landley.net>, "Baoquan He" <bhe@redhat.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
"Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
xen-devel@lists.xenproject.org, "kvm list" <kvm@vger.kernel.org>,
"Linux PM list" <linux-pm@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
linux-sparse@vger.kernel.org,
"Kernel Hardening" <kernel-hardening@lists.openwall.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"Borislav Petkov" <bp@alien8.de>
Subject: [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization
Date: Tue, 15 Aug 2017 07:58:47 -0700 [thread overview]
Message-ID: <CAJcbSZHJ_Jy=dr4Pc3-o_Bz340cLRgu79Up5iWptwaiObwN3Hw@mail.gmail.com> (raw)
In-Reply-To: <CA+DvKQLM-a-0z985o6NQtfLtxC-K_KSkns4MyfdMUmrq7Kbtjw@mail.gmail.com>
On Tue, Aug 15, 2017 at 7:47 AM, Daniel Micay <danielmicay@gmail.com> wrote:
> On 15 August 2017 at 10:20, Thomas Garnier <thgarnie@google.com> wrote:
>> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> * Thomas Garnier <thgarnie@google.com> wrote:
>>>
>>>> > Do these changes get us closer to being able to build the kernel as truly
>>>> > position independent, i.e. to place it anywhere in the valid x86-64 address
>>>> > space? Or any other advantages?
>>>>
>>>> Yes, PIE allows us to put the kernel anywhere in memory. It will allow us to
>>>> have a full randomized address space where position and order of sections are
>>>> completely random. There is still some work to get there but being able to build
>>>> a PIE kernel is a significant step.
>>>
>>> So I _really_ dislike the whole PIE approach, because of the huge slowdown:
>>>
>>> +config RANDOMIZE_BASE_LARGE
>>> + bool "Increase the randomization range of the kernel image"
>>> + depends on X86_64 && RANDOMIZE_BASE
>>> + select X86_PIE
>>> + select X86_MODULE_PLTS if MODULES
>>> + default n
>>> + ---help---
>>> + Build the kernel as a Position Independent Executable (PIE) and
>>> + increase the available randomization range from 1GB to 3GB.
>>> +
>>> + This option impacts performance on kernel CPU intensive workloads up
>>> + to 10% due to PIE generated code. Impact on user-mode processes and
>>> + typical usage would be significantly less (0.50% when you build the
>>> + kernel).
>>> +
>>> + The kernel and modules will generate slightly more assembly (1 to 2%
>>> + increase on the .text sections). The vmlinux binary will be
>>> + significantly smaller due to less relocations.
>>>
>>> To put 10% kernel overhead into perspective: enabling this option wipes out about
>>> 5-10 years worth of painstaking optimizations we've done to keep the kernel fast
>>> ... (!!)
>>
>> Note that 10% is the high-bound of a CPU intensive workload.
>
> The cost can be reduced by using -fno-plt these days but some work
> might be required to make that work with the kernel.
>
> Where does that 10% estimate in the kernel config docs come from? I'd
> be surprised if it really cost that much on x86_64. That's a realistic
> cost for i386 with modern GCC (it used to be worse) but I'd expect
> x86_64 to be closer to 2% even for CPU intensive workloads. It should
> be very close to zero with -fno-plt.
I got 8 to 10% on hackbench. Other benchmarks were 4% or lower.
I will do look at more recent compiler and no-plt as well.
--
Thomas
next prev parent reply other threads:[~2017-08-15 14:58 UTC|newest]
Thread overview: 221+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-10 17:25 x86: PIE support and option to extend KASLR randomization Thomas Garnier
2017-08-10 17:25 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 01/23] x86/crypto: Adapt assembly for PIE support Thomas Garnier
2017-08-10 17:25 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 02/23] x86: Use symbol name on bug table " Thomas Garnier
2017-08-10 17:25 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 03/23] x86: Use symbol name in jump " Thomas Garnier
2017-08-10 17:25 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 04/23] x86: Add macro to get symbol address " Thomas Garnier
2017-08-10 17:25 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 05/23] xen: Adapt assembly " Thomas Garnier
2017-08-10 17:25 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 06/23] kvm: " Thomas Garnier
2017-08-10 17:25 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 07/23] x86: relocate_kernel - " Thomas Garnier
2017-08-10 17:25 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 08/23] x86/entry/64: " Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 09/23] x86: pm-trace - " Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 10/23] x86/CPU: " Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 11/23] x86/acpi: " Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 12/23] x86/boot/64: " Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 13/23] x86/power/64: " Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-11 12:36 ` Pavel Machek
2017-08-11 12:36 ` Pavel Machek
2017-08-11 12:36 ` [kernel-hardening] " Pavel Machek
2017-08-11 15:09 ` Thomas Garnier
2017-08-11 15:09 ` [kernel-hardening] " Thomas Garnier
2017-08-11 15:09 ` Thomas Garnier
2017-08-10 17:26 ` [RFC v2 14/23] x86/paravirt: " Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 15/23] x86/boot/64: Use _text in a global " Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 16/23] x86/percpu: Adapt percpu " Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 17/23] compiler: Option to default to hidden symbols Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 18/23] x86/relocs: Handle DYN relocations for PIE support Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 19/23] x86: Support global stack cookie Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 20/23] x86/pie: Add option to build the kernel as PIE for x86_64 Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 21/23] x86/relocs: Add option to generate 64-bit relocations Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 22/23] x86/module: Add support for mcmodel large and PLTs Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 23/23] x86/kaslr: Add option to extend KASLR range from 1GB to 3GB Thomas Garnier
2017-08-10 17:26 ` [kernel-hardening] " Thomas Garnier
2017-08-11 12:41 ` x86: PIE support and option to extend KASLR randomization Ingo Molnar
2017-08-11 12:41 ` [kernel-hardening] " Ingo Molnar
2017-08-11 15:09 ` Thomas Garnier
2017-08-11 15:09 ` Thomas Garnier
2017-08-11 15:09 ` [kernel-hardening] " Thomas Garnier
2017-08-15 7:56 ` Ingo Molnar
2017-08-15 7:56 ` Ingo Molnar
2017-08-15 7:56 ` [kernel-hardening] " Ingo Molnar
2017-08-15 12:15 ` Jordan Glover
2017-08-15 13:42 ` Rik van Riel
2017-08-15 14:20 ` Thomas Garnier
2017-08-15 14:20 ` Thomas Garnier
2017-08-15 14:20 ` [kernel-hardening] " Thomas Garnier
2017-08-15 14:47 ` Daniel Micay
2017-08-15 14:47 ` Daniel Micay
2017-08-15 14:47 ` [kernel-hardening] " Daniel Micay
2017-08-15 14:58 ` Thomas Garnier
2017-08-15 14:58 ` Thomas Garnier [this message]
2017-08-15 14:58 ` [kernel-hardening] " Thomas Garnier
2017-08-16 15:12 ` Ingo Molnar
2017-08-16 15:12 ` Ingo Molnar
2017-08-16 15:12 ` [kernel-hardening] " Ingo Molnar
2017-08-16 16:09 ` Christopher Lameter
2017-08-16 16:09 ` Christopher Lameter
2017-08-16 16:09 ` [kernel-hardening] " Christopher Lameter
2017-08-16 16:26 ` Daniel Micay
2017-08-16 16:26 ` [kernel-hardening] " Daniel Micay
2017-08-16 16:32 ` Ard Biesheuvel
2017-08-16 16:32 ` Ard Biesheuvel
2017-08-16 16:32 ` [kernel-hardening] " Ard Biesheuvel
2017-08-16 16:26 ` Daniel Micay
2017-08-16 16:57 ` Thomas Garnier
2017-08-16 16:57 ` Thomas Garnier
2017-08-16 16:57 ` [kernel-hardening] " Thomas Garnier
2017-08-17 8:09 ` Ingo Molnar
2017-08-17 8:09 ` Ingo Molnar
2017-08-17 8:09 ` [kernel-hardening] " Ingo Molnar
2017-08-17 14:10 ` Thomas Garnier
2017-08-17 14:10 ` Thomas Garnier
2017-08-17 14:10 ` [kernel-hardening] " Thomas Garnier
2017-08-24 21:13 ` Thomas Garnier
2017-08-24 21:13 ` Thomas Garnier
2017-08-24 21:13 ` [kernel-hardening] " Thomas Garnier
2017-08-24 21:42 ` Linus Torvalds
2017-08-24 21:42 ` Linus Torvalds
2017-08-24 21:42 ` [kernel-hardening] " Linus Torvalds
2017-08-25 15:35 ` Thomas Garnier
2017-08-25 15:35 ` [kernel-hardening] " Thomas Garnier
2017-08-25 15:35 ` Thomas Garnier
2017-08-25 1:07 ` Steven Rostedt
2017-08-25 1:07 ` [kernel-hardening] " Steven Rostedt
2017-08-25 8:04 ` Ingo Molnar
2017-08-25 8:04 ` Ingo Molnar
2017-08-25 8:04 ` [kernel-hardening] " Ingo Molnar
2017-08-25 15:05 ` Thomas Garnier
2017-08-25 15:05 ` Thomas Garnier
2017-08-25 15:05 ` [kernel-hardening] " Thomas Garnier
2017-08-29 19:34 ` Thomas Garnier
2017-08-29 19:34 ` [kernel-hardening] " Thomas Garnier
2017-09-21 15:59 ` Ingo Molnar
2017-09-21 15:59 ` [kernel-hardening] " Ingo Molnar
2017-09-21 16:10 ` Ard Biesheuvel
2017-09-21 16:10 ` Ard Biesheuvel
2017-09-21 16:10 ` [kernel-hardening] " Ard Biesheuvel
2017-09-21 21:21 ` Thomas Garnier
2017-09-21 21:21 ` Thomas Garnier
2017-09-21 21:21 ` [kernel-hardening] " Thomas Garnier
2017-09-22 4:24 ` Markus Trippelsdorf
2017-09-22 4:24 ` [kernel-hardening] " Markus Trippelsdorf
2017-09-22 14:38 ` Thomas Garnier
2017-09-22 14:38 ` [kernel-hardening] " Thomas Garnier
2017-09-22 14:38 ` Thomas Garnier
2017-09-22 23:55 ` Thomas Garnier
2017-09-22 23:55 ` Thomas Garnier
2017-09-22 23:55 ` [kernel-hardening] " Thomas Garnier
2017-09-21 21:16 ` Thomas Garnier
2017-09-21 21:16 ` [kernel-hardening] " Thomas Garnier
2017-09-22 0:06 ` Thomas Garnier
2017-09-22 0:06 ` Thomas Garnier
2017-09-22 0:06 ` [kernel-hardening] " Thomas Garnier
2017-09-22 16:32 ` Ingo Molnar
2017-09-22 16:32 ` [kernel-hardening] " Ingo Molnar
2017-09-22 18:08 ` Thomas Garnier
2017-09-22 18:08 ` Thomas Garnier
2017-09-22 18:08 ` [kernel-hardening] " Thomas Garnier
2017-09-23 9:43 ` Ingo Molnar
2017-09-23 9:43 ` [kernel-hardening] " Ingo Molnar
2017-10-02 20:28 ` Thomas Garnier
2017-10-02 20:28 ` Thomas Garnier
2017-10-02 20:28 ` [kernel-hardening] " Thomas Garnier
2017-09-23 9:43 ` Ingo Molnar
2017-09-22 18:38 ` H. Peter Anvin
2017-09-22 18:38 ` [kernel-hardening] " H. Peter Anvin
2017-09-22 18:57 ` Kees Cook
2017-09-22 18:57 ` [kernel-hardening] " Kees Cook
2017-09-22 19:06 ` H. Peter Anvin
2017-09-22 19:06 ` [kernel-hardening] " H. Peter Anvin
2017-09-22 22:19 ` hjl.tools
2017-09-22 22:30 ` hjl.tools
2017-09-22 19:06 ` H. Peter Anvin
2017-09-22 18:57 ` Kees Cook
2017-09-22 18:59 ` Thomas Garnier
2017-09-22 18:59 ` Thomas Garnier
2017-09-22 18:59 ` [kernel-hardening] " Thomas Garnier
2017-09-23 9:49 ` Ingo Molnar
2017-09-23 9:49 ` Ingo Molnar
2017-09-23 9:49 ` [kernel-hardening] " Ingo Molnar
2017-09-22 18:38 ` H. Peter Anvin
2017-09-22 16:32 ` Ingo Molnar
2017-09-21 21:16 ` Thomas Garnier
2017-09-21 15:59 ` Ingo Molnar
2017-08-29 19:34 ` Thomas Garnier
2017-08-17 14:12 ` Boris Lukashev
2017-08-17 14:12 ` [kernel-hardening] " Boris Lukashev
2017-08-25 15:38 ` Christopher Lameter
2017-08-25 15:38 ` [kernel-hardening] " Christopher Lameter
2017-08-27 22:39 ` Boris Lukashev
2017-08-27 22:39 ` Boris Lukashev
2017-08-27 22:39 ` [kernel-hardening] " Boris Lukashev
2017-08-25 15:38 ` Christopher Lameter
2017-08-28 9:59 ` Pavel Machek
2017-08-28 9:59 ` Pavel Machek
2017-08-28 9:59 ` [kernel-hardening] " Pavel Machek
2017-08-17 14:12 ` Boris Lukashev
2017-08-21 13:32 ` Peter Zijlstra
2017-08-21 13:32 ` [kernel-hardening] " Peter Zijlstra
2017-08-21 14:28 ` Peter Zijlstra
2017-08-21 14:28 ` Peter Zijlstra
2017-08-21 14:28 ` [kernel-hardening] " Peter Zijlstra
2017-09-22 18:27 ` H. Peter Anvin
2017-09-22 18:27 ` [kernel-hardening] " H. Peter Anvin
2017-09-23 10:00 ` Ingo Molnar
2017-09-23 10:00 ` [kernel-hardening] " Ingo Molnar
2017-09-24 22:37 ` Pavel Machek
2017-09-24 22:37 ` [kernel-hardening] " Pavel Machek
2017-09-25 7:33 ` Ingo Molnar
2017-09-25 7:33 ` Ingo Molnar
2017-09-25 7:33 ` [kernel-hardening] " Ingo Molnar
2017-10-06 10:39 ` Pavel Machek
2017-10-06 10:39 ` Pavel Machek
2017-10-06 10:39 ` [kernel-hardening] " Pavel Machek
2017-10-20 8:13 ` Ingo Molnar
2017-10-20 8:13 ` [kernel-hardening] " Ingo Molnar
2017-10-20 8:13 ` Ingo Molnar
2017-09-24 22:37 ` Pavel Machek
2017-09-23 10:00 ` Ingo Molnar
2017-09-22 18:27 ` H. Peter Anvin
2017-08-21 13:32 ` Peter Zijlstra
2017-08-21 14:31 ` Peter Zijlstra
2017-08-21 14:31 ` [kernel-hardening] " Peter Zijlstra
2017-08-21 15:57 ` Thomas Garnier
2017-08-21 15:57 ` Thomas Garnier
2017-08-21 15:57 ` [kernel-hardening] " Thomas Garnier
2017-08-28 1:26 ` H. Peter Anvin
2017-08-28 1:26 ` [kernel-hardening] " H. Peter Anvin
2017-08-28 1:26 ` H. Peter Anvin
2017-08-21 14:31 ` Peter Zijlstra
2017-08-11 12:41 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2017-10-04 21:19 Thomas Garnier
2017-10-04 21:19 Thomas Garnier via Virtualization
2017-10-04 21:19 Thomas Garnier
2017-10-04 21:19 ` Thomas Garnier
2017-08-10 17:25 Thomas Garnier
2017-07-18 22:33 Thomas Garnier
2017-07-19 14:08 ` Christopher Lameter
2017-07-19 14:08 ` Christopher Lameter
2017-07-18 22:33 Thomas Garnier
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='CAJcbSZHJ_Jy=dr4Pc3-o_Bz340cLRgu79Up5iWptwaiObwN3Hw@mail.gmail.com' \
--to=thgarnie@google.com \
--cc=arnd@arndb.de \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@suse.de \
--cc=brgerst@gmail.com \
--cc=danielmicay@gmail.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=joro@8bytes.org \
--cc=jpoimboe@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=len.brown@intel.com \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=mka@chromium.org \
--cc=pavel@ucw.cz \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.