Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Tue, Jan 10, 2017 at 2:27 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> Coming back on that after a bit more testing. The LTR instruction >> check if the busy bit is already set, if already set then it will just >> issue a #GP given a bad

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Tue, Jan 10, 2017 at 2:27 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> Coming back on that after a bit more testing. The LTR instruction >> check if the busy bit is already set, if already set then it will just >> issue a #GP given a bad selector: >> >> [0.00] general

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > Coming back on that after a bit more testing. The LTR instruction > check if the busy bit is already set, if already set then it will just > issue a #GP given a bad selector: > > [0.00] general protection fault: 0040 [#1] SMP > ... > [

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > Coming back on that after a bit more testing. The LTR instruction > check if the busy bit is already set, if already set then it will just > issue a #GP given a bad selector: > > [0.00] general protection fault: 0040 [#1] SMP > ... > [0.00] RIP:

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 11:35 PM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> > No, and I had the way this worked on 64-bit wrong. LTR requires an >> > available TSS and changes it to busy. So here are my thoughts on how >> > this should work: >> >

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 11:35 PM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> > No, and I had the way this worked on 64-bit wrong. LTR requires an >> > available TSS and changes it to busy. So here are my thoughts on how >> > this should work: >> > >> > Let's get rid of any connection

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 11:35 PM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> > No, and I had the way this worked on 64-bit wrong. LTR requires an >> > available TSS and changes it to busy. So here are my thoughts on how >> > this should work: >> >

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 11:35 PM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> > No, and I had the way this worked on 64-bit wrong. LTR requires an >> > available TSS and changes it to busy. So here are my thoughts on how >> > this should work: >> > >> > Let's get rid of any connection

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 11:45 PM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: >> P.S. Let's do the move to the fixmap, read/write as a separate patch. That >> will >> make bisecting much easier. > > Absolutely, but this has to be within the same series, as

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 11:45 PM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: >> P.S. Let's do the move to the fixmap, read/write as a separate patch. That >> will >> make bisecting much easier. > > Absolutely, but this has to be within the same series, as the interim > fixmap-only > step

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Andy Lutomirski wrote: > > When I looked at the fixmap, you had to define the space you need ahead of > > time and I am not sure there was enough space as you said. > > Can you try it and see if anything goes wrong? Even if something does go > wrong, > I think we should

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Andy Lutomirski wrote: > > When I looked at the fixmap, you had to define the space you need ahead of > > time and I am not sure there was enough space as you said. > > Can you try it and see if anything goes wrong? Even if something does go > wrong, > I think we should fix *that* rather

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Andy Lutomirski wrote: > > I looked back at the fixmap, and I can see a way it could be done (using > > NR_CPUS) like the other fixmap ranges. It would limit the number of cpus to > > 512 (there is 2M memory left on fixmap on the default configuration). > > That's > > if

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Andy Lutomirski wrote: > > I looked back at the fixmap, and I can see a way it could be done (using > > NR_CPUS) like the other fixmap ranges. It would limit the number of cpus to > > 512 (there is 2M memory left on fixmap on the default configuration). > > That's > > if we never add any

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > > No, and I had the way this worked on 64-bit wrong. LTR requires an > > available TSS and changes it to busy. So here are my thoughts on how > > this should work: > > > > Let's get rid of any connection between this code and KASLR. Every > >

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > > No, and I had the way this worked on 64-bit wrong. LTR requires an > > available TSS and changes it to busy. So here are my thoughts on how > > this should work: > > > > Let's get rid of any connection between this code and KASLR. Every > > time KASLR makes

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 2:54 PM, Thomas Garnier wrote: > On Fri, Jan 6, 2017 at 1:59 PM, Andy Lutomirski wrote: >> On Fri, Jan 6, 2017 at 10:03 AM, Thomas Garnier wrote: >>> On Thu, Jan 5, 2017 at 10:49 PM, Ingo Molnar

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 2:54 PM, Thomas Garnier wrote: > On Fri, Jan 6, 2017 at 1:59 PM, Andy Lutomirski wrote: >> On Fri, Jan 6, 2017 at 10:03 AM, Thomas Garnier wrote: >>> On Thu, Jan 5, 2017 at 10:49 PM, Ingo Molnar wrote: * Thomas Garnier wrote: > >> Not sure I fully

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 1:59 PM, Andy Lutomirski wrote: > On Fri, Jan 6, 2017 at 10:03 AM, Thomas Garnier wrote: >> On Thu, Jan 5, 2017 at 10:49 PM, Ingo Molnar wrote: >>> >>> * Thomas Garnier wrote: >>> >> Not

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 1:59 PM, Andy Lutomirski wrote: > On Fri, Jan 6, 2017 at 10:03 AM, Thomas Garnier wrote: >> 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.

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 10:03 AM, Thomas Garnier wrote: > 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 10:03 AM, Thomas Garnier wrote: > 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 10:02 AM, Thomas Garnier wrote: > On Thu, Jan 5, 2017 at 6:34 PM, Andy Lutomirski wrote: >> On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds >> wrote: >>> On Thu, Jan 5, 2017 at 12:18 PM, Andy

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 10:02 AM, Thomas Garnier wrote: > On Thu, Jan 5, 2017 at 6:34 PM, Andy Lutomirski wrote: >> On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds >> wrote: >>> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: Hmm. I bet that if we preset the accessed bits in

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 9:44 AM, Borislav Petkov wrote: > On Thu, Jan 05, 2017 at 08:40:29AM -0800, Thomas Garnier wrote: >> > kernel_unrandomize_smp() ... >> > >> >> That seems like a better name. > > Hardly... I'd call it something like kaslr_load_gdt() to actually say > what

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 9:44 AM, Borislav Petkov wrote: > On Thu, Jan 05, 2017 at 08:40:29AM -0800, Thomas Garnier wrote: >> > kernel_unrandomize_smp() ... >> > >> >> That seems like a better name. > > Hardly... I'd call it something like kaslr_load_gdt() to actually say > what this function is

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 >> >>

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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 6:34 PM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds > wrote: >> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >>> >>> Hmm. I bet that if we preset the accessed

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 6:34 PM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds > wrote: >> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >>> >>> Hmm. I bet that if we preset the accessed bits in all the segments >>> then we don't need it to be writable in

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 05, 2017 at 08:40:29AM -0800, Thomas Garnier wrote: > > kernel_unrandomize_smp() ... > > > > That seems like a better name. Hardly... I'd call it something like kaslr_load_gdt() to actually say what this function is doing. -- Regards/Gruss, Boris. Good mailing practices for

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 05, 2017 at 08:40:29AM -0800, Thomas Garnier wrote: > > kernel_unrandomize_smp() ... > > > > That seems like a better name. Hardly... I'd call it something like kaslr_load_gdt() to actually say what this function is doing. -- Regards/Gruss, Boris. Good mailing practices for

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* 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:

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Arjan van de Ven wrote: > On 1/5/2017 9:54 AM, Thomas Garnier wrote: > > > That's my goal too. I started by doing a RO remap and got couple problems > > with > > hibernation. I can try again for the next iteration or delay it for another > > patch. I also need to

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Arjan van de Ven wrote: > On 1/5/2017 9:54 AM, Thomas Garnier wrote: > > > That's my goal too. I started by doing a RO remap and got couple problems > > with > > hibernation. I can try again for the next iteration or delay it for another > > patch. I also need to look at KVM GDT usage, I

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > > Thanks, > > > > Ingo > > Ingo: I saw the 5-level page table support being sent through. Do you > want me to wait for it to be -next? (Given it will need to be changed > too). Please just base your bits on Linus's latest tree - we'll

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > > Thanks, > > > > Ingo > > Ingo: I saw the 5-level page table support being sent through. Do you > want me to wait for it to be -next? (Given it will need to be changed > too). Please just base your bits on Linus's latest tree - we'll sort out any conflicts

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds wrote: > On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >> >> Hmm. I bet that if we preset the accessed bits in all the segments >> then we don't need it to be writable in general. > > I'm

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds wrote: > On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >> >> Hmm. I bet that if we preset the accessed bits in all the segments >> then we don't need it to be writable in general. > > I'm not sure that this is architecturally safe. >

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds wrote: > On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >> >> Hmm. I bet that if we preset the accessed bits in all the segments >> then we don't need it to be writable in general. > > I'm

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds wrote: > On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >> >> Hmm. I bet that if we preset the accessed bits in all the segments >> then we don't need it to be writable in general. > > I'm not sure that this is architecturally safe. > >

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: > > Hmm. I bet that if we preset the accessed bits in all the segments > then we don't need it to be writable in general. I'm not sure that this is architecturally safe. IIRC, we do mark the IDT read-only - but that one

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: > > Hmm. I bet that if we preset the accessed bits in all the segments > then we don't need it to be writable in general. I'm not sure that this is architecturally safe. IIRC, we do mark the IDT read-only - but that one we started doing

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 1:19 PM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 1:08 PM, Thomas Garnier wrote: >> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >>> On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 1:19 PM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 1:08 PM, Thomas Garnier wrote: >> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >>> On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote: On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 1:08 PM, Thomas Garnier wrote: > On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >> On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote: >>> On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 1:08 PM, Thomas Garnier wrote: > On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >> On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote: >>> On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven >>> wrote: On 1/5/2017 9:54 AM, Thomas Garnier wrote: >

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote: >> On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven >> wrote: >>> On 1/5/2017 9:54 AM, Thomas Garnier wrote: >>>

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote: >> On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven >> wrote: >>> On 1/5/2017 9:54 AM, Thomas Garnier wrote: >>> That's my goal too. I started by doing a RO remap and got

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote: > On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven > wrote: >> On 1/5/2017 9:54 AM, Thomas Garnier wrote: >> >>> >>> That's my goal too. I started by doing a RO remap and got couple >>> problems

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote: > On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven > wrote: >> On 1/5/2017 9:54 AM, Thomas Garnier wrote: >> >>> >>> That's my goal too. I started by doing a RO remap and got couple >>> problems with hibernation. I can try again for the

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven wrote: > On 1/5/2017 9:54 AM, Thomas Garnier wrote: > >> >> That's my goal too. I started by doing a RO remap and got couple >> problems with hibernation. I can try again for the next iteration or >> delay it for another

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven wrote: > On 1/5/2017 9:54 AM, Thomas Garnier wrote: > >> >> That's my goal too. I started by doing a RO remap and got couple >> problems with hibernation. I can try again for the next iteration or >> delay it for another patch. I also need to look

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:56 AM, Arjan van de Ven wrote: > On 1/5/2017 8:40 AM, Thomas Garnier wrote: >> >> Well, it happens only when KASLR memory randomization is enabled. Do >> you think it should have a separate config option? > > > no I would want it a runtime

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:56 AM, Arjan van de Ven wrote: > On 1/5/2017 8:40 AM, Thomas Garnier wrote: >> >> Well, it happens only when KASLR memory randomization is enabled. Do >> you think it should have a separate config option? > > > no I would want it a runtime option "sgdt from ring 3"

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 9:54 AM, Thomas Garnier wrote: That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet. don't we write to

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 9:54 AM, Thomas Garnier wrote: That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet. don't we write to

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 8:40 AM, Thomas Garnier wrote: Well, it happens only when KASLR memory randomization is enabled. Do you think it should have a separate config option? no I would want it a runtime option "sgdt from ring 3" is going away with UMIP (and is already possibly gone in virtual

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 8:40 AM, Thomas Garnier wrote: Well, it happens only when KASLR memory randomization is enabled. Do you think it should have a separate config option? no I would want it a runtime option "sgdt from ring 3" is going away with UMIP (and is already possibly gone in virtual

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:01 AM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 9:54 AM, Thomas Garnier wrote: >> On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski wrote: >>> On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:01 AM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 9:54 AM, Thomas Garnier wrote: >> On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski wrote: >>> On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier wrote: Each processor holds a GDT in its per-cpu structure. The sgdt

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 9:54 AM, Thomas Garnier wrote: > On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski wrote: >> On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier wrote: >>> Each processor holds a GDT in its per-cpu structure. The

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 9:54 AM, Thomas Garnier wrote: > On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski wrote: >> On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier wrote: >>> Each processor holds a GDT in its per-cpu structure. The sgdt >>> instruction gives the base address of the current GDT.

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski wrote: > On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier 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 >>

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski wrote: > On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 7:08 AM, Arjan van de Ven wrote: > On 1/5/2017 12:11 AM, Ingo Molnar wrote: >> >> >> * Thomas Garnier wrote: >> >>> Each processor holds a GDT in its per-cpu structure. The sgdt >>> instruction gives the base address of the

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 7:08 AM, Arjan van de Ven wrote: > On 1/5/2017 12:11 AM, Ingo Molnar wrote: >> >> >> * Thomas Garnier 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 12:11 AM, Ingo Molnar wrote: > > * Thomas Garnier 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 12:11 AM, Ingo Molnar wrote: > > * Thomas Garnier 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 >>

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 12:11 AM, Ingo Molnar wrote: * Thomas Garnier 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 12:11 AM, Ingo Molnar wrote: * Thomas Garnier 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier 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

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier 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

[RFC] x86/mm/KASLR: Remap GDTs at fixed location

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

[RFC] x86/mm/KASLR: Remap GDTs at fixed location

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