All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Thomas Garnier <thgarnie@google.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Kees Cook <keescook@chromium.org>,
	Juergen Gross <jgross@suse.com>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Andy Lutomirski <luto@kernel.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>, zijun_hu <zijun_hu@htc.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Jiri Kosina <jikos@kernel.org>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Rusty Russell <rusty@rust>
Subject: Re: [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section
Date: Thu, 9 Mar 2017 13:32:03 -0800	[thread overview]
Message-ID: <CALCETrVXHc-EAhBtdhL9FXSW1G2VbohRY4UJuOtpRG1K0Q-Ogg@mail.gmail.com> (raw)
In-Reply-To: <20170306220348.79702-2-thgarnie@google.com>

On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier <thgarnie@google.com> wrote:
> Each processor holds a GDT in its per-cpu structure. The sgdt
> instruction gives the base address of the current GDT. This address can
> be used to bypass KASLR memory randomization. With another bug, an
> attacker could target other per-cpu structures or deduce the base of
> the main memory section (PAGE_OFFSET).
>
> This patch relocates the GDT table for each processor inside the
> Fixmap section. The space is reserved based on number of supported
> processors.
>
> For consistency, the remapping is done by default on 32 and 64-bit.
>
> Each processor switches to its remapped GDT at the end of
> initialization. For hibernation, the main processor returns with the
> original GDT and switches back to the remapping at completion.
>
> This patch was tested on both architectures. Hibernation and KVM were
> both tested specially for their usage of the GDT.

Looks good with minor nitpicks.  Also, have you tested on Xen PV?

(If you aren't set up for it, virtme can do this test quite easily.  I
could run it for you if you like, too.)

> +static inline unsigned long get_current_gdt_rw_vaddr(void)
> +{
> +       return (unsigned long)get_current_gdt_rw();
> +}

This has no callers, so let's remove it.

> +static inline unsigned long get_cpu_gdt_ro_vaddr(int cpu)
> +{
> +       return (unsigned long)get_cpu_gdt_ro(cpu);
> +}

Ditto.

> +static inline unsigned long get_current_gdt_ro_vaddr(void)
> +{
> +       return (unsigned long)get_current_gdt_ro();
> +}

Ditto.

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct *t,
>
>         *shadow = t->tls_array[i];
>
> -       gdt = get_cpu_gdt_table(cpu);
> +       gdt = get_cpu_gdt_rw(cpu);
>         maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
>         mc = __xen_mc_entry(0);

Boris, is this right?  I don't see why it wouldn't be, but Xen is special.

> @@ -504,7 +504,7 @@ void __init lguest_arch_host_init(void)
>                  * byte, not the size, hence the "-1").
>                  */
>                 state->host_gdt_desc.size = GDT_SIZE-1;
> -               state->host_gdt_desc.address = (long)get_cpu_gdt_table(i);
> +               state->host_gdt_desc.address = (long)get_cpu_gdt_rw(i);

I suspect this should be get_cpu_gdt_ro(), but I don't know too much
about lguest.  Hmm, maybe the right thing to do is to give lguest a
nice farewell and retire it.  The last time I tried to test it, I gave
up.


--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net>
To: Thomas Garnier <thgarnie@google.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Kees Cook <keescook@chromium.org>,
	Juergen Gross <jgross@suse.com>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Andy Lutomirski <luto@kernel.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>, zijun_hu <zijun_hu@htc.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Jiri Kosina <jikos@kernel.org>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Rusty Russell <rusty@rust
Subject: Re: [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section
Date: Thu, 9 Mar 2017 13:32:03 -0800	[thread overview]
Message-ID: <CALCETrVXHc-EAhBtdhL9FXSW1G2VbohRY4UJuOtpRG1K0Q-Ogg@mail.gmail.com> (raw)
In-Reply-To: <20170306220348.79702-2-thgarnie@google.com>

On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier <thgarnie@google.com> wrote:
> Each processor holds a GDT in its per-cpu structure. The sgdt
> instruction gives the base address of the current GDT. This address can
> be used to bypass KASLR memory randomization. With another bug, an
> attacker could target other per-cpu structures or deduce the base of
> the main memory section (PAGE_OFFSET).
>
> This patch relocates the GDT table for each processor inside the
> Fixmap section. The space is reserved based on number of supported
> processors.
>
> For consistency, the remapping is done by default on 32 and 64-bit.
>
> Each processor switches to its remapped GDT at the end of
> initialization. For hibernation, the main processor returns with the
> original GDT and switches back to the remapping at completion.
>
> This patch was tested on both architectures. Hibernation and KVM were
> both tested specially for their usage of the GDT.

Looks good with minor nitpicks.  Also, have you tested on Xen PV?

(If you aren't set up for it, virtme can do this test quite easily.  I
could run it for you if you like, too.)

> +static inline unsigned long get_current_gdt_rw_vaddr(void)
> +{
> +       return (unsigned long)get_current_gdt_rw();
> +}

This has no callers, so let's remove it.

> +static inline unsigned long get_cpu_gdt_ro_vaddr(int cpu)
> +{
> +       return (unsigned long)get_cpu_gdt_ro(cpu);
> +}

Ditto.

> +static inline unsigned long get_current_gdt_ro_vaddr(void)
> +{
> +       return (unsigned long)get_current_gdt_ro();
> +}

Ditto.

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct *t,
>
>         *shadow = t->tls_array[i];
>
> -       gdt = get_cpu_gdt_table(cpu);
> +       gdt = get_cpu_gdt_rw(cpu);
>         maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
>         mc = __xen_mc_entry(0);

Boris, is this right?  I don't see why it wouldn't be, but Xen is special.

> @@ -504,7 +504,7 @@ void __init lguest_arch_host_init(void)
>                  * byte, not the size, hence the "-1").
>                  */
>                 state->host_gdt_desc.size = GDT_SIZE-1;
> -               state->host_gdt_desc.address = (long)get_cpu_gdt_table(i);
> +               state->host_gdt_desc.address = (long)get_cpu_gdt_rw(i);

I suspect this should be get_cpu_gdt_ro(), but I don't know too much
about lguest.  Hmm, maybe the right thing to do is to give lguest a
nice farewell and retire it.  The last time I tried to test it, I gave
up.


--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net>
To: Thomas Garnier <thgarnie@google.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Andrey Ryabinin" <aryabinin@virtuozzo.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Juergen Gross" <jgross@suse.com>,
	"Lorenzo Stoakes" <lstoakes@gmail.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Paul Gortmaker" <paul.gortmaker@windriver.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Michal Hocko" <mhocko@suse.com>, zijun_hu <zijun_hu@htc.com>,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Joonsoo Kim" <iamjoonsoo.kim@lge.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	"Len Brown" <len.brown@intel.com>, "Pavel Machek" <pavel@ucw.cz>,
	"Jiri Kosina" <jikos@kernel.org>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Rusty Russell" <rusty@rustcorp.com.au>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	"Fenghua Yu" <fenghua.yu@intel.com>,
	"He Chen" <he.chen@linux.intel.com>,
	"Brian Gerst" <brgerst@gmail.com>,
	"Frederic Weisbecker" <fweisbec@gmail.com>,
	"Stanislaw Gruszka" <sgruszka@redhat.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Josh Poimboeuf" <jpoimboe@redhat.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	"David Vrabel" <david.vrabel@citrix.com>,
	"Tim Chen" <tim.c.chen@linux.intel.com>,
	"Andi Kleen" <ak@linux.intel.com>, "Jiri Olsa" <jolsa@redhat.com>,
	"Prarit Bhargava" <prarit@redhat.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Radim Krčmář" <rkrcmar@redhat.com>, "X86 ML" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	lguest@lists.ozlabs.org, "kvm list" <kvm@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section
Date: Thu, 9 Mar 2017 13:32:03 -0800	[thread overview]
Message-ID: <CALCETrVXHc-EAhBtdhL9FXSW1G2VbohRY4UJuOtpRG1K0Q-Ogg@mail.gmail.com> (raw)
In-Reply-To: <20170306220348.79702-2-thgarnie@google.com>

On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier <thgarnie@google.com> wrote:
> Each processor holds a GDT in its per-cpu structure. The sgdt
> instruction gives the base address of the current GDT. This address can
> be used to bypass KASLR memory randomization. With another bug, an
> attacker could target other per-cpu structures or deduce the base of
> the main memory section (PAGE_OFFSET).
>
> This patch relocates the GDT table for each processor inside the
> Fixmap section. The space is reserved based on number of supported
> processors.
>
> For consistency, the remapping is done by default on 32 and 64-bit.
>
> Each processor switches to its remapped GDT at the end of
> initialization. For hibernation, the main processor returns with the
> original GDT and switches back to the remapping at completion.
>
> This patch was tested on both architectures. Hibernation and KVM were
> both tested specially for their usage of the GDT.

Looks good with minor nitpicks.  Also, have you tested on Xen PV?

(If you aren't set up for it, virtme can do this test quite easily.  I
could run it for you if you like, too.)

> +static inline unsigned long get_current_gdt_rw_vaddr(void)
> +{
> +       return (unsigned long)get_current_gdt_rw();
> +}

This has no callers, so let's remove it.

> +static inline unsigned long get_cpu_gdt_ro_vaddr(int cpu)
> +{
> +       return (unsigned long)get_cpu_gdt_ro(cpu);
> +}

Ditto.

> +static inline unsigned long get_current_gdt_ro_vaddr(void)
> +{
> +       return (unsigned long)get_current_gdt_ro();
> +}

Ditto.

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct *t,
>
>         *shadow = t->tls_array[i];
>
> -       gdt = get_cpu_gdt_table(cpu);
> +       gdt = get_cpu_gdt_rw(cpu);
>         maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
>         mc = __xen_mc_entry(0);

Boris, is this right?  I don't see why it wouldn't be, but Xen is special.

> @@ -504,7 +504,7 @@ void __init lguest_arch_host_init(void)
>                  * byte, not the size, hence the "-1").
>                  */
>                 state->host_gdt_desc.size = GDT_SIZE-1;
> -               state->host_gdt_desc.address = (long)get_cpu_gdt_table(i);
> +               state->host_gdt_desc.address = (long)get_cpu_gdt_rw(i);

I suspect this should be get_cpu_gdt_ro(), but I don't know too much
about lguest.  Hmm, maybe the right thing to do is to give lguest a
nice farewell and retire it.  The last time I tried to test it, I gave
up.


--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net>
To: Thomas Garnier <thgarnie@google.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Andrey Ryabinin" <aryabinin@virtuozzo.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Juergen Gross" <jgross@suse.com>,
	"Lorenzo Stoakes" <lstoakes@gmail.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Paul Gortmaker" <paul.gortmaker@windriver.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Michal Hocko" <mhocko@suse.com>, zijun_hu <zijun_hu@htc.com>,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Joonsoo Kim" <iamjoonsoo.kim@lge.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	"Len Brown" <len.brown@intel.com>, "Pavel Machek" <pavel@ucw.cz>,
	"Jiri Kosina" <jikos@kernel.org>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Rusty Russell" <rusty@rustcorp.com.au>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	"Fenghua Yu" <fenghua.yu@intel.com>,
	"He Chen" <he.chen@linux.intel.com>,
	"Brian Gerst" <brgerst@gmail.com>,
	"Frederic Weisbecker" <fweisbec@gmail.com>,
	"Stanislaw Gruszka" <sgruszka@redhat.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Josh Poimboeuf" <jpoimboe@redhat.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	"David Vrabel" <david.vrabel@citrix.com>,
	"Tim Chen" <tim.c.chen@linux.intel.com>,
	"Andi Kleen" <ak@linux.intel.com>, "Jiri Olsa" <jolsa@redhat.com>,
	"Prarit Bhargava" <prarit@redhat.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Radim Krčmář" <rkrcmar@redhat.com>, "X86 ML" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	lguest@lists.ozlabs.org, "kvm list" <kvm@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section
Date: Thu, 9 Mar 2017 13:32:03 -0800	[thread overview]
Message-ID: <CALCETrVXHc-EAhBtdhL9FXSW1G2VbohRY4UJuOtpRG1K0Q-Ogg@mail.gmail.com> (raw)
In-Reply-To: <20170306220348.79702-2-thgarnie@google.com>

On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier <thgarnie@google.com> wrote:
> Each processor holds a GDT in its per-cpu structure. The sgdt
> instruction gives the base address of the current GDT. This address can
> be used to bypass KASLR memory randomization. With another bug, an
> attacker could target other per-cpu structures or deduce the base of
> the main memory section (PAGE_OFFSET).
>
> This patch relocates the GDT table for each processor inside the
> Fixmap section. The space is reserved based on number of supported
> processors.
>
> For consistency, the remapping is done by default on 32 and 64-bit.
>
> Each processor switches to its remapped GDT at the end of
> initialization. For hibernation, the main processor returns with the
> original GDT and switches back to the remapping at completion.
>
> This patch was tested on both architectures. Hibernation and KVM were
> both tested specially for their usage of the GDT.

Looks good with minor nitpicks.  Also, have you tested on Xen PV?

(If you aren't set up for it, virtme can do this test quite easily.  I
could run it for you if you like, too.)

> +static inline unsigned long get_current_gdt_rw_vaddr(void)
> +{
> +       return (unsigned long)get_current_gdt_rw();
> +}

This has no callers, so let's remove it.

> +static inline unsigned long get_cpu_gdt_ro_vaddr(int cpu)
> +{
> +       return (unsigned long)get_cpu_gdt_ro(cpu);
> +}

Ditto.

> +static inline unsigned long get_current_gdt_ro_vaddr(void)
> +{
> +       return (unsigned long)get_current_gdt_ro();
> +}

Ditto.

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct *t,
>
>         *shadow = t->tls_array[i];
>
> -       gdt = get_cpu_gdt_table(cpu);
> +       gdt = get_cpu_gdt_rw(cpu);
>         maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
>         mc = __xen_mc_entry(0);

Boris, is this right?  I don't see why it wouldn't be, but Xen is special.

> @@ -504,7 +504,7 @@ void __init lguest_arch_host_init(void)
>                  * byte, not the size, hence the "-1").
>                  */
>                 state->host_gdt_desc.size = GDT_SIZE-1;
> -               state->host_gdt_desc.address = (long)get_cpu_gdt_table(i);
> +               state->host_gdt_desc.address = (long)get_cpu_gdt_rw(i);

I suspect this should be get_cpu_gdt_ro(), but I don't know too much
about lguest.  Hmm, maybe the right thing to do is to give lguest a
nice farewell and retire it.  The last time I tried to test it, I gave
up.


--Andy

  parent reply	other threads:[~2017-03-09 21:32 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-06 22:03 [PATCH v5 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size Thomas Garnier
2017-03-06 22:03 ` [kernel-hardening] " Thomas Garnier
2017-03-06 22:03 ` Thomas Garnier
2017-03-06 22:03 ` Thomas Garnier
2017-03-06 22:03 ` [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section Thomas Garnier
2017-03-06 22:03 ` Thomas Garnier
2017-03-06 22:03   ` [kernel-hardening] " Thomas Garnier
2017-03-06 22:03   ` Thomas Garnier
2017-03-06 22:03   ` Thomas Garnier
2017-03-09 21:32   ` Andy Lutomirski
2017-03-09 21:32   ` Andy Lutomirski [this message]
2017-03-09 21:32     ` [kernel-hardening] " Andy Lutomirski
2017-03-09 21:32     ` Andy Lutomirski
2017-03-09 21:32     ` Andy Lutomirski
2017-03-09 21:43     ` Andrew Cooper
2017-03-09 21:43       ` [kernel-hardening] Re: [Xen-devel] " Andrew Cooper
2017-03-09 21:43       ` Andrew Cooper
2017-03-09 21:46       ` Andy Lutomirski
2017-03-09 21:46         ` [kernel-hardening] " Andy Lutomirski
2017-03-09 21:46         ` Andy Lutomirski
2017-03-09 21:54         ` Thomas Garnier
2017-03-09 21:54         ` [Xen-devel] " Thomas Garnier
2017-03-09 21:54           ` [kernel-hardening] " Thomas Garnier
2017-03-09 21:54           ` Thomas Garnier
2017-03-09 21:56           ` Boris Ostrovsky
2017-03-09 21:56           ` [Xen-devel] " Boris Ostrovsky
2017-03-09 21:56             ` [kernel-hardening] " Boris Ostrovsky
2017-03-09 21:56             ` Boris Ostrovsky
2017-03-09 22:13             ` Boris Ostrovsky
2017-03-09 22:13             ` [Xen-devel] " Boris Ostrovsky
2017-03-09 22:13               ` [kernel-hardening] " Boris Ostrovsky
2017-03-09 22:13               ` Boris Ostrovsky
2017-03-09 22:31               ` Thomas Garnier
2017-03-09 22:31               ` [Xen-devel] " Thomas Garnier
2017-03-09 22:31                 ` [kernel-hardening] " Thomas Garnier
2017-03-09 22:31                 ` Thomas Garnier
2017-03-09 23:17                 ` Boris Ostrovsky
2017-03-09 23:17                 ` [Xen-devel] " Boris Ostrovsky
2017-03-09 23:17                   ` [kernel-hardening] " Boris Ostrovsky
2017-03-09 23:17                   ` Boris Ostrovsky
2017-03-13 18:32                   ` Boris Ostrovsky
2017-03-13 18:32                   ` [Xen-devel] " Boris Ostrovsky
2017-03-13 18:32                     ` [kernel-hardening] " Boris Ostrovsky
2017-03-13 18:32                     ` Boris Ostrovsky
2017-03-13 19:24                     ` Thomas Garnier
2017-03-13 19:24                       ` [kernel-hardening] " Thomas Garnier
2017-03-13 19:24                       ` Thomas Garnier
2017-03-13 19:24                     ` Thomas Garnier
2017-03-09 21:46       ` Andy Lutomirski
2017-03-06 22:03 ` [PATCH v5 3/3] x86: Make the GDT remapping read-only on 64-bit Thomas Garnier
2017-03-06 22:03 ` Thomas Garnier
2017-03-06 22:03   ` [kernel-hardening] " Thomas Garnier
2017-03-06 22:03   ` Thomas Garnier
2017-03-06 22:03   ` Thomas Garnier
2017-03-09 21:35   ` Andy Lutomirski
2017-03-09 21:35   ` Andy Lutomirski
2017-03-09 21:35     ` [kernel-hardening] " Andy Lutomirski
2017-03-09 21:35     ` Andy Lutomirski
2017-03-09 21:35     ` Andy Lutomirski

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=CALCETrVXHc-EAhBtdhL9FXSW1G2VbohRY4UJuOtpRG1K0Q-Ogg@mail.gmail.com \
    --to=luto@amacapital.net \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=corbet@lwn.net \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jgross@suse.com \
    --cc=jikos@kernel.org \
    --cc=keescook@chromium.org \
    --cc=len.brown@intel.com \
    --cc=lstoakes@gmail.com \
    --cc=luto@kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=rusty@rust \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=zijun_hu@htc.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.