Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Jan 2017 10:03:51 -0800
From: Thomas Garnier <>
To: Ingo Molnar <>
Cc: Andy Lutomirski <>, Andy Lutomirski <>, 
	Arjan van de Ven <>, Thomas Gleixner <>, 
	Ingo Molnar <>, "H . Peter Anvin" <>, Kees Cook <>, 
	Borislav Petkov <>, Dave Hansen <>, Chen Yucong <>, 
	Paul Gortmaker <>, Andrew Morton <>, 
	Masahiro Yamada <>, 
	Sebastian Andrzej Siewior <>, Anna-Maria Gleixner <>, 
	Boris Ostrovsky <>, Rasmus Villemoes <>, 
	Michael Ellerman <>, Juergen Gross <>, 
	Richard Weinberger <>, X86 ML <>, 
	"" <>, 
	"" <>
Subject: Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:49 PM, Ingo Molnar <> wrote:
> * Thomas Garnier <> 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?

That was my experience. I didn't look into details. Do you think we
could change something so that ltr never writes to the GDT? (just mark
the TSS entry busy).

> Thanks,
>         Ingo


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.