From: Ingo Molnar <mingo@kernel.org>
To: Thomas Garnier <thgarnie@google.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Andy Lutomirski <luto@kernel.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
Kees Cook <keescook@chromium.org>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave@sr71.net>, Chen Yucong <slaoub@gmail.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Anna-Maria Gleixner <anna-maria@linutronix.de>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Michael Ellerman <mpe@ellerman.id.au>,
Juergen Gross <jgross@suse.com>,
Richard Weinberger <richard@nod.at>, X86 ML <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location
Date: Fri, 6 Jan 2017 07:49:00 +0100 [thread overview]
Message-ID: <20170106064900.GC28091@gmail.com> (raw)
In-Reply-To: <CAJcbSZETh-A+zABOzsx+VW3p73AXO4xnc=O_TG7iXaVbD=Zz1A@mail.gmail.com>
* Thomas Garnier <thgarnie@google.com> wrote:
> >> Not sure I fully understood and I don't want to miss an important point. Do
> >> you mean making GDT (remapping and per-cpu) read-only and switch the
> >> writeable flag only when we write to the per-cpu entry?
> >
> > What I mean is: write to the GDT through normal percpu access (or whatever the
> > normal mapping is) but load a read-only alias into the GDT register. As long
> > as nothing ever tries to write through the GDTR alias, no page faults will be
> > generated. So we just need to make sure that nothing ever writes to it
> > through GDTR. AFAIK the only reason the CPU ever writes to the address in
> > GDTR is to set an accessed bit.
>
> A write is made when we use load_TR_desc (ltr). I didn't see any other yet.
Is this write to the GDT, generated by the LTR instruction, done unconditionally
by the hardware?
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Thomas Garnier <thgarnie@google.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Andy Lutomirski <luto@kernel.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
Kees Cook <keescook@chromium.org>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave@sr71.net>, Chen Yucong <slaoub@gmail.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Anna-Maria Gleixner <anna-maria@linutronix.de>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Michael Ellerman <mpe@ellerman.id.au>,
Juergen Gross <jgross@suse.com>,
Richard Weinberger <richard@nod.at>, X86 ML <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location
Date: Fri, 6 Jan 2017 07:49:00 +0100 [thread overview]
Message-ID: <20170106064900.GC28091@gmail.com> (raw)
In-Reply-To: <CAJcbSZETh-A+zABOzsx+VW3p73AXO4xnc=O_TG7iXaVbD=Zz1A@mail.gmail.com>
* Thomas Garnier <thgarnie@google.com> wrote:
> >> Not sure I fully understood and I don't want to miss an important point. Do
> >> you mean making GDT (remapping and per-cpu) read-only and switch the
> >> writeable flag only when we write to the per-cpu entry?
> >
> > What I mean is: write to the GDT through normal percpu access (or whatever the
> > normal mapping is) but load a read-only alias into the GDT register. As long
> > as nothing ever tries to write through the GDTR alias, no page faults will be
> > generated. So we just need to make sure that nothing ever writes to it
> > through GDTR. AFAIK the only reason the CPU ever writes to the address in
> > GDTR is to set an accessed bit.
>
> A write is made when we use load_TR_desc (ltr). I didn't see any other yet.
Is this write to the GDT, generated by the LTR instruction, done unconditionally
by the hardware?
Thanks,
Ingo
next prev parent reply other threads:[~2017-01-06 6:49 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 22:16 [kernel-hardening] [RFC] x86/mm/KASLR: Remap GDTs at fixed location Thomas Garnier
2017-01-04 22:16 ` Thomas Garnier
2017-01-05 8:11 ` [kernel-hardening] " Ingo Molnar
2017-01-05 8:11 ` Ingo Molnar
2017-01-05 15:08 ` [kernel-hardening] " Arjan van de Ven
2017-01-05 15:08 ` Arjan van de Ven
2017-01-05 16:40 ` [kernel-hardening] " Thomas Garnier
2017-01-05 16:40 ` Thomas Garnier
2017-01-05 18:56 ` [kernel-hardening] " Arjan van de Ven
2017-01-05 18:56 ` Arjan van de Ven
2017-01-05 19:00 ` [kernel-hardening] " Thomas Garnier
2017-01-05 19:00 ` Thomas Garnier
2017-01-06 17:44 ` [kernel-hardening] " Borislav Petkov
2017-01-06 17:44 ` Borislav Petkov
2017-01-06 18:04 ` [kernel-hardening] " Thomas Garnier
2017-01-06 18:04 ` Thomas Garnier
2017-01-05 16:39 ` [kernel-hardening] " Thomas Garnier
2017-01-05 16:39 ` Thomas Garnier
2017-01-06 6:34 ` [kernel-hardening] " Ingo Molnar
2017-01-06 6:34 ` Ingo Molnar
2017-01-05 17:51 ` [kernel-hardening] " Andy Lutomirski
2017-01-05 17:51 ` Andy Lutomirski
2017-01-05 17:54 ` [kernel-hardening] " Thomas Garnier
2017-01-05 17:54 ` Thomas Garnier
2017-01-05 18:01 ` [kernel-hardening] " Andy Lutomirski
2017-01-05 18:01 ` Andy Lutomirski
2017-01-05 18:35 ` [kernel-hardening] " Thomas Garnier
2017-01-05 18:35 ` Thomas Garnier
2017-01-05 18:58 ` [kernel-hardening] " Arjan van de Ven
2017-01-05 18:58 ` Arjan van de Ven
2017-01-05 19:03 ` [kernel-hardening] " Thomas Garnier
2017-01-05 19:03 ` Thomas Garnier
2017-01-05 20:18 ` [kernel-hardening] " Andy Lutomirski
2017-01-05 20:18 ` Andy Lutomirski
2017-01-05 21:08 ` [kernel-hardening] " Thomas Garnier
2017-01-05 21:08 ` Thomas Garnier
2017-01-05 21:19 ` [kernel-hardening] " Andy Lutomirski
2017-01-05 21:19 ` Andy Lutomirski
2017-01-05 21:58 ` [kernel-hardening] " Thomas Garnier
2017-01-05 21:58 ` Thomas Garnier
2017-01-06 6:49 ` Ingo Molnar [this message]
2017-01-06 6:49 ` Ingo Molnar
2017-01-06 18:03 ` [kernel-hardening] " Thomas Garnier
2017-01-06 18:03 ` Thomas Garnier
2017-01-06 21:59 ` [kernel-hardening] " Andy Lutomirski
2017-01-06 21:59 ` Andy Lutomirski
2017-01-06 22:54 ` [kernel-hardening] " Thomas Garnier
2017-01-06 22:54 ` Thomas Garnier
2017-01-06 23:39 ` [kernel-hardening] " Andy Lutomirski
2017-01-06 23:39 ` Andy Lutomirski
2017-01-07 7:45 ` [kernel-hardening] " Ingo Molnar
2017-01-07 7:45 ` Ingo Molnar
2017-01-07 15:58 ` [kernel-hardening] " Andy Lutomirski
2017-01-07 15:58 ` Andy Lutomirski
2017-01-07 7:35 ` [kernel-hardening] " Ingo Molnar
2017-01-07 7:35 ` Ingo Molnar
2017-01-07 16:02 ` [kernel-hardening] " Andy Lutomirski
2017-01-07 16:02 ` Andy Lutomirski
2017-01-09 22:32 ` [kernel-hardening] " Thomas Garnier
2017-01-09 22:32 ` Thomas Garnier
2017-01-10 10:27 ` [kernel-hardening] " Ingo Molnar
2017-01-10 10:27 ` Ingo Molnar
2017-01-10 17:13 ` [kernel-hardening] " Thomas Garnier
2017-01-10 17:13 ` Thomas Garnier
2017-01-05 23:05 ` [kernel-hardening] " Linus Torvalds
2017-01-05 23:05 ` Linus Torvalds
2017-01-05 23:16 ` [kernel-hardening] " Thomas Garnier
2017-01-05 23:16 ` Thomas Garnier
2017-01-06 2:34 ` [kernel-hardening] " Andy Lutomirski
2017-01-06 2:34 ` Andy Lutomirski
2017-01-06 18:02 ` [kernel-hardening] " Thomas Garnier
2017-01-06 18:02 ` Thomas Garnier
2017-01-06 21:53 ` [kernel-hardening] " Andy Lutomirski
2017-01-06 21:53 ` Andy Lutomirski
2017-01-07 7:46 ` [kernel-hardening] " Ingo Molnar
2017-01-07 7:46 ` Ingo Molnar
2017-01-06 6:45 ` [kernel-hardening] " Ingo Molnar
2017-01-06 6:45 ` Ingo Molnar
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=20170106064900.GC28091@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anna-maria@linutronix.de \
--cc=arjan@linux.intel.com \
--cc=bigeasy@linutronix.de \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave@sr71.net \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=paul.gortmaker@windriver.com \
--cc=richard@nod.at \
--cc=slaoub@gmail.com \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.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.