[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVXHc-EAhBtdhL9FXSW1G2VbohRY4UJuOtpRG1K0Q-Ogg@mail.gmail.com>
Date: Thu, 9 Mar 2017 13:32:03 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Thomas Garnier <thgarnie@...gle.com>, Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
"H . Peter Anvin" <hpa@...or.com>, Jonathan Corbet <corbet@....net>,
Andrey Ryabinin <aryabinin@...tuozzo.com>, Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>, Kees Cook <keescook@...omium.org>,
Juergen Gross <jgross@...e.com>, Lorenzo Stoakes <lstoakes@...il.com>, Andy Lutomirski <luto@...nel.org>,
Paul Gortmaker <paul.gortmaker@...driver.com>, Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>, zijun_hu <zijun_hu@....com>,
Chris Wilson <chris@...is-wilson.co.uk>, Joonsoo Kim <iamjoonsoo.kim@....com>,
"Rafael J . Wysocki" <rjw@...ysocki.net>, Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
Jiri Kosina <jikos@...nel.org>, Matt Fleming <matt@...eblueprint.co.uk>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>, Rusty Russell <rusty@...tcorp.com.au>,
Paolo Bonzini <pbonzini@...hat.com>, Borislav Petkov <bp@...e.de>,
Christian Borntraeger <borntraeger@...ibm.com>, "Luis R . Rodriguez" <mcgrof@...nel.org>,
Fenghua Yu <fenghua.yu@...el.com>, He Chen <he.chen@...ux.intel.com>,
Brian Gerst <brgerst@...il.com>, Frederic Weisbecker <fweisbec@...il.com>,
Stanislaw Gruszka <sgruszka@...hat.com>, Arnd Bergmann <arnd@...db.de>,
Peter Zijlstra <peterz@...radead.org>, Dave Hansen <dave.hansen@...el.com>,
Josh Poimboeuf <jpoimboe@...hat.com>, Vitaly Kuznetsov <vkuznets@...hat.com>,
David Vrabel <david.vrabel@...rix.com>, Tim Chen <tim.c.chen@...ux.intel.com>,
Andi Kleen <ak@...ux.intel.com>, Jiri Olsa <jolsa@...hat.com>,
Prarit Bhargava <prarit@...hat.com>, Michael Ellerman <mpe@...erman.id.au>, Joerg Roedel <joro@...tes.org>,
Radim Krčmář <rkrcmar@...hat.com>,
X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, kasan-dev <kasan-dev@...glegroups.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>, lguest@...ts.ozlabs.org,
kvm list <kvm@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH v5 2/3] x86: Remap GDT tables in the Fixmap section
On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier <thgarnie@...gle.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
