On 04/10/2013 09:31 AM, Eric Northup wrote:
>>
>> If the effect is measurable I agree it is a legitimate optimization. At
>> one point there was a suggestion to make the code in the IDT vectors
>> differ based on the which interrupt was registed. While that can also
>> reduce cache misses that ca
On Wed, Apr 10, 2013 at 3:40 AM, Eric W. Biederman
wrote:
> Ingo Molnar writes:
>
>> * Eric W. Biederman wrote:
>>
>>> "H. Peter Anvin" writes:
>>>
>>> > On 04/08/2013 03:43 PM, Kees Cook wrote:
>>> >> This makes the IDT unconditionally read-only. This primarily removes
>>> >> the IDT from bein
Ingo Molnar writes:
> * Eric W. Biederman wrote:
>
>> "H. Peter Anvin" writes:
>>
>> > On 04/08/2013 03:43 PM, Kees Cook wrote:
>> >> This makes the IDT unconditionally read-only. This primarily removes
>> >> the IDT from being a target for arbitrary memory write attacks. It has
>> >> an added
* Eric W. Biederman wrote:
> "H. Peter Anvin" writes:
>
> > On 04/08/2013 03:43 PM, Kees Cook wrote:
> >> This makes the IDT unconditionally read-only. This primarily removes
> >> the IDT from being a target for arbitrary memory write attacks. It has
> >> an added benefit of also not leaking (
* H. Peter Anvin wrote:
> On 04/09/2013 11:22 AM, Kees Cook wrote:
> >
> > Can we create a RO fixed per-cpu area?
> >
>
> "Fixed" and "percpu" are mutually exclusive...
There's a fixmap area that holds kmap_atomic() percpu mappings:
FIX_KMAP_BEGIN, /* reserved pte's for temporary ke
* Kees Cook wrote:
> > That's the area in which we just map 1:1 to memory. Anything allocated
> > with
> > e.g. kmalloc() ends up with those addresses.
>
> Ah-ha! Yes, I see now when comparing the debug/kernel_page_tables reports.
> It's
> just the High Kernel Mapping that we care about. A
On 04/09/2013 11:22 AM, Kees Cook wrote:
>
> Can we create a RO fixed per-cpu area?
>
"Fixed" and "percpu" are mutually exclusive...
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On 04/09/2013 11:54 AM, Eric Northup wrote:
>
> The GDT is a problem if the address returned by 'sgdt' is
> kernel-writable - it doesn't necessarily reveal the random offset, but
> I'm pretty sure that writing to the GDT could cause privilege
> escalation.
>
That is a pretty safe assumption...
On 04/09/2013 11:46 AM, Kees Cook wrote:
>
> Ah-ha! Yes, I see now when comparing the debug/kernel_page_tables
> reports. It's just the High Kernel Mapping that we care about.
> Addresses outside that range are less of a leak. Excellent, then GDT
> may not be a problem. Whew.
>
It does beg the q
On Tue, Apr 9, 2013 at 11:46 AM, Kees Cook wrote:
> On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin wrote:
>> On 04/09/2013 11:31 AM, Kees Cook wrote:
> ...
> 0x880001e0-0x88001fe0 480M RW PSE GLB
> NX pmd
>
That is the 1:1 memory map
On Tue, Apr 9, 2013 at 11:50 AM, H. Peter Anvin wrote:
> On 04/09/2013 11:46 AM, Kees Cook wrote:
>>
>> Ah-ha! Yes, I see now when comparing the debug/kernel_page_tables
>> reports. It's just the High Kernel Mapping that we care about.
>> Addresses outside that range are less of a leak. Excellent,
On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin wrote:
> On 04/09/2013 11:31 AM, Kees Cook wrote:
...
0x880001e0-0x88001fe0 480M RW PSE GLB
NX pmd
>>>
>>> That is the 1:1 memory map area...
>>
>> Meaning what?
>>
>> -Kees
>>
>
> That's the a
On 04/09/2013 11:31 AM, Kees Cook wrote:
>>> ...
>>> 0x880001e0-0x88001fe0 480M RW PSE GLB
>>> NX pmd
>>>
>>
>> That is the 1:1 memory map area...
>
> Meaning what?
>
> -Kees
>
That's the area in which we just map 1:1 to memory. Anything allocated
with e.g.
On Tue, Apr 9, 2013 at 11:26 AM, H. Peter Anvin wrote:
> On 04/09/2013 11:22 AM, Kees Cook wrote:
>>
>> $ ./sgdt
>> 88001fc04000
>> # cat /sys/kernel/debug/kernel_page_tables
>> ...
>> ---[ Low Kernel Mapping ]---
>> ...
>> 0x880001e0-0x88001fe0 480M RW PSE
On 04/09/2013 11:22 AM, Kees Cook wrote:
>
> $ ./sgdt
> 88001fc04000
> # cat /sys/kernel/debug/kernel_page_tables
> ...
> ---[ Low Kernel Mapping ]---
> ...
> 0x880001e0-0x88001fe0 480M RW PSE GLB NX
> pmd
>
That is the 1:1 memory map area...
-hp
On Tue, Apr 9, 2013 at 2:23 AM, Thomas Gleixner wrote:
> On Mon, 8 Apr 2013, H. Peter Anvin wrote:
>
>> On 04/08/2013 03:43 PM, Kees Cook wrote:
>> > This makes the IDT unconditionally read-only. This primarily removes
>> > the IDT from being a target for arbitrary memory write attacks. It has
>>
"H. Peter Anvin" writes:
> On 04/08/2013 03:43 PM, Kees Cook wrote:
>> This makes the IDT unconditionally read-only. This primarily removes
>> the IDT from being a target for arbitrary memory write attacks. It has
>> an added benefit of also not leaking (via the "sidt" instruction) the
>> kernel
On Mon, 8 Apr 2013, H. Peter Anvin wrote:
> On 04/08/2013 03:43 PM, Kees Cook wrote:
> > This makes the IDT unconditionally read-only. This primarily removes
> > the IDT from being a target for arbitrary memory write attacks. It has
> > an added benefit of also not leaking (via the "sidt" instruct
On Mon, 8 Apr 2013, Kees Cook wrote:
> > FWIW the change looks reasonable to me, however given that that it makes
> > the arrangement unconditional and there is no longer a workaround to
> > enable I think it would make sense to remove the conditional block quoted
> > above altogether, along with
On Mon, Apr 8, 2013 at 3:56 PM, Maciej W. Rozycki wrote:
> On Mon, 8 Apr 2013, Kees Cook wrote:
>
>> This makes the IDT unconditionally read-only. This primarily removes
>> the IDT from being a target for arbitrary memory write attacks. It has
>> an added benefit of also not leaking (via the "sidt
On Mon, 8 Apr 2013, Kees Cook wrote:
> This makes the IDT unconditionally read-only. This primarily removes
> the IDT from being a target for arbitrary memory write attacks. It has
> an added benefit of also not leaking (via the "sidt" instruction) the
> kernel base offset, if it has been relocate
On Mon, Apr 8, 2013 at 3:56 PM, Maciej W. Rozycki wrote:
> On Mon, 8 Apr 2013, Kees Cook wrote:
>
>> This makes the IDT unconditionally read-only. This primarily removes
>> the IDT from being a target for arbitrary memory write attacks. It has
>> an added benefit of also not leaking (via the "sidt
On Mon, Apr 8, 2013 at 3:47 PM, H. Peter Anvin wrote:
> On 04/08/2013 03:43 PM, Kees Cook wrote:
>> This makes the IDT unconditionally read-only. This primarily removes
>> the IDT from being a target for arbitrary memory write attacks. It has
>> an added benefit of also not leaking (via the "sidt"
On 04/08/2013 03:43 PM, Kees Cook wrote:
> This makes the IDT unconditionally read-only. This primarily removes
> the IDT from being a target for arbitrary memory write attacks. It has
> an added benefit of also not leaking (via the "sidt" instruction) the
> kernel base offset, if it has been reloc
On 04/08/2013 03:43 PM, Kees Cook wrote:
> This makes the IDT unconditionally read-only. This primarily removes
> the IDT from being a target for arbitrary memory write attacks. It has
> an added benefit of also not leaking (via the "sidt" instruction) the
> kernel base offset, if it has been reloc
This makes the IDT unconditionally read-only. This primarily removes
the IDT from being a target for arbitrary memory write attacks. It has
an added benefit of also not leaking (via the "sidt" instruction) the
kernel base offset, if it has been relocated.
Signed-off-by: Kees Cook
Cc: Eric Northup
26 matches
Mail list logo
