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 protec
* 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: 0010:na
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 be
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 be
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 i
* 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
* 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 o
* 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 somethi
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 unde
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. Do
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 an
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 al
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 doi
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-
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 gene
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 400
* 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
* 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 a
* 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 as
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.
>
Hmm.
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.
>
> IIR
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 du
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
wrot
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:
>
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
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 nex
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
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" is
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 t
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 machines
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
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. Thi
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 per-cpu
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 randomizatio
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 bypas
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
>> at
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 other
* 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 ba
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
39 matches
Mail list logo