All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Garnier <thgarnie@google.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: "X86 ML" <x86@kernel.org>,
	"Stanislaw Gruszka" <sgruszka@redhat.com>,
	"kvm list" <kvm@vger.kernel.org>,
	"Fenghua Yu" <fenghua.yu@intel.com>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Paul Gortmaker" <paul.gortmaker@windriver.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"Alexander Potapenko" <glider@google.com>,
	"Pavel Machek" <pavel@ucw.cz>, "H . Peter Anvin" <hpa@zytor.com>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	"Jiri Olsa" <jolsa@redhat.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Andi Kleen" <ak@linux.intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Prarit Bhargava" <prarit@redhat.com>,
	kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [PATCH v2 3/3] x86: Make the GDT remapping read-only on 64 bit
Date: Mon, 6 Feb 2017 14:10:36 -0800	[thread overview]
Message-ID: <CAJcbSZHiL3OmswxAJ9gVkC9a4O01qdiy7yjsb5dvofhOn8s+8Q__27909.8370614976$1486419182$gmane$org@mail.gmail.com> (raw)
In-Reply-To: <CALCETrU=KY7QgdLWm43LA=_jpu_oXJgGLqv0yUVr4vR7ROYh0Q@mail.gmail.com>

On Wed, Feb 1, 2017 at 9:14 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On Thu, Jan 26, 2017 at 8:59 AM, Thomas Garnier <thgarnie@google.com> wrote:
>> This patch makes the GDT remapped pages read-only to prevent corruption.
>> This change is done only on 64 bit.
>>
>> The native_load_tr_desc function was adapted to correctly handle a
>> read-only GDT. The LTR instruction always writes to the GDT TSS entry.
>> This generates a page fault if the GDT is read-only. This change checks
>> if the current GDT is a remap and swap GDTs as needed. This function was
>> tested by booting multiple machines and checking hibernation works
>> properly.
>>
>> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
>> per-cpu variable was removed for functions to fetch the original GDT.
>> Instead of reloading the previous GDT, VMX will reload the fixmap GDT as
>> expected. For testing, VMs were started and restored on multiple
>> configurations.
>>
>> Signed-off-by: Thomas Garnier <thgarnie@google.com>
>> ---
>> Based on next-20170125
>> ---
>>  arch/x86/include/asm/desc.h      | 46 +++++++++++++++++++++++++++++++++++-----
>>  arch/x86/include/asm/processor.h |  1 +
>>  arch/x86/kernel/cpu/common.c     | 28 ++++++++++++++++++------
>>  arch/x86/kvm/svm.c               |  4 +---
>>  arch/x86/kvm/vmx.c               | 15 +++++--------
>>  5 files changed, 70 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
>> index 4cc176f57b78..ca7b2224fcb4 100644
>> --- a/arch/x86/include/asm/desc.h
>> +++ b/arch/x86/include/asm/desc.h
>> @@ -52,6 +52,12 @@ static inline struct desc_struct *get_cpu_direct_gdt(unsigned int cpu)
>>         return per_cpu(gdt_page, cpu).gdt;
>>  }
>>
>> +/* Provide the current original GDT */
>> +static inline struct desc_struct *get_current_direct_gdt(void)
>> +{
>> +       return this_cpu_ptr(&gdt_page)->gdt;
>> +}
>
> I'm assuming that the reason that this isn't part of patch 2 and used
> instead of the version that takes cpu as a parameter is that TLS
> doesn't work until the GDT is set up.  If so, perhaps that's worthy of
> a comment in patch 2.
>
> But give this_cpu_read(gdt_page.gdt) a try, please.
>

I tried but I can't get it working properly because the gdt field is
an array, not a pointer. For example with this_cpu_read(gdt_page.gdt),
I get:

./arch/x86/include/asm/desc.h: In function ‘get_current_gdt_rw’:
./include/linux/percpu-defs.h:308:21: error: incompatible types when
assigning to type ‘struct desc_struct[16]’ from type ‘struct
desc_struct *’
  case 1: pscr_ret__ = stem##1(variable); break;   \
                     ^
I tried different variants without success. What do you think?

>> +/*
>> + * The LTR instruction marks the TSS GDT entry as busy. In 64bit, the GDT is
>> + * a read-only remapping. To prevent a page fault, the GDT is switched to the
>> + * original writeable version when needed.
>> + */
>> +#ifdef CONFIG_X86_64
>> +static inline void native_load_tr_desc(void)
>> +{
>> +       struct desc_ptr gdt;
>> +       int cpu = raw_smp_processor_id();
>> +       bool restore = false;
>> +       struct desc_struct *fixmap_gdt;
>> +
>> +       native_store_gdt(&gdt);
>
> Off the top of my head, this is something like 10 cycles.  IMO that's
> fast enough not to worry about the regression this will cause to KVM
> exits.  In any event, we'll get that back and *much* more when we do
> the optimizations that this series enables.



-- 
Thomas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-02-06 22:10 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-26 16:59 [PATCH v2 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size Thomas Garnier
2017-01-26 16:59 ` [kernel-hardening] " Thomas Garnier
2017-01-26 16:59 ` Thomas Garnier
2017-01-26 16:59 ` Thomas Garnier
2017-01-26 16:59 ` [PATCH v2 2/3] x86: Remap GDT tables in the Fixmap section Thomas Garnier
2017-01-26 16:59 ` Thomas Garnier
2017-01-26 16:59   ` [kernel-hardening] " Thomas Garnier
2017-01-26 16:59   ` Thomas Garnier
2017-01-26 16:59   ` Thomas Garnier
2017-01-26 18:52   ` Andy Lutomirski
2017-01-26 18:52     ` [kernel-hardening] " Andy Lutomirski
2017-01-26 19:10     ` Thomas Garnier
2017-01-26 19:10       ` [kernel-hardening] " Thomas Garnier
2017-01-26 19:10     ` Thomas Garnier
2017-01-26 18:52   ` Andy Lutomirski
2017-01-26 16:59 ` [PATCH v2 3/3] x86: Make the GDT remapping read-only on 64 bit Thomas Garnier
2017-01-26 16:59 ` Thomas Garnier
2017-01-26 16:59   ` [kernel-hardening] " Thomas Garnier
2017-01-26 16:59   ` Thomas Garnier
2017-01-26 16:59   ` Thomas Garnier
2017-02-01  9:15   ` Ingo Molnar
2017-02-01  9:15     ` [kernel-hardening] " Ingo Molnar
2017-02-01  9:15     ` Ingo Molnar
2017-02-02  5:13     ` Andy Lutomirski
2017-02-02  5:13     ` Andy Lutomirski
2017-02-02  5:13       ` [kernel-hardening] " Andy Lutomirski
2017-02-02  5:13       ` Andy Lutomirski
2017-02-02  7:12       ` Ingo Molnar
2017-02-02  7:12         ` [kernel-hardening] " Ingo Molnar
2017-02-02  7:12         ` Ingo Molnar
2017-02-02  7:12       ` Ingo Molnar
2017-02-01  9:15   ` Ingo Molnar
2017-02-02  5:14   ` Andy Lutomirski
2017-02-02  5:14   ` Andy Lutomirski
2017-02-02  5:14     ` [kernel-hardening] " Andy Lutomirski
2017-02-06 22:10     ` Thomas Garnier [this message]
2017-02-06 22:10     ` Thomas Garnier
2017-02-06 22:10       ` [kernel-hardening] " 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='CAJcbSZHiL3OmswxAJ9gVkC9a4O01qdiy7yjsb5dvofhOn8s+8Q__27909.8370614976$1486419182$gmane$org@mail.gmail.com' \
    --to=thgarnie@google.com \
    --cc=ak@linux.intel.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dave.hansen@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mpe@ellerman.id.au \
    --cc=paul.gortmaker@windriver.com \
    --cc=pavel@ucw.cz \
    --cc=prarit@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sgruszka@redhat.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.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
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.