* 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
* 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.
* Kees Cook keesc...@chromium.org 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
* H. Peter Anvin h...@zytor.com 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
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
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
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
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.
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
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
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...
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
>>
On Tue, Apr 9, 2013 at 2:23 AM, Thomas Gleixner t...@linutronix.de 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.
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...
-hpa
--
H.
On Tue, Apr 9, 2013 at 11:26 AM, H. Peter Anvin h...@zytor.com 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: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. kmalloc() ends up
On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin h...@zytor.com 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 area in which we just
On Tue, Apr 9, 2013 at 11:50 AM, H. Peter Anvin h...@zytor.com 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.
On Tue, Apr 9, 2013 at 11:46 AM, Kees Cook keesc...@chromium.org wrote:
On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin h...@zytor.com wrote:
On 04/09/2013 11:31 AM, Kees Cook wrote:
...
0x880001e0-0x88001fe0 480M RW PSE GLB
NX pmd
That is the 1:1
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
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: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 info at
24 matches
Mail list logo
