* Re: Bug#852324: x86/mm: Found insecure W+X mapping
[not found] ` <1489625430.2852.30.camel@decadent.org.uk>
@ 2017-03-16 21:05 ` Ben Hutchings
2017-03-16 21:49 ` Andrew Cooper
0 siblings, 1 reply; 5+ messages in thread
From: Ben Hutchings @ 2017-03-16 21:05 UTC (permalink / raw)
To: 852324, xen-devel; +Cc: Boris Ostrovsky, Jan Beulich, To: Diederik de Haas
[-- Attachment #1.1: Type: text/plain, Size: 2567 bytes --]
On Thu, 2017-03-16 at 00:50 +0000, Ben Hutchings wrote:
> On Wed, 2017-03-15 at 22:24 +0000, Ben Hutchings wrote:
> > Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
> > Control: tag -1 upstream confirmed
> > Control: found -1 4.9.13-1
> >
> > I can reproduce this with a current Debian kernel on top of Xen 4.4.
> > It doesn't happen with the same hardware booting the kernel directly.
>
> With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of the
> low kernel mapping is mapped with W+X permissions, with a few
> exceptions:
>
> 0xffff880000000000-0xffff880000099000 612K USR RW x pte
> 0xffff880000099000-0xffff88000009a000 4K USR ro NX pte
> 0xffff88000009a000-0xffff88000009b000 4K USR ro x pte
> 0xffff88000009b000-0xffff88000009f000 16K USR RW NX pte
> 0xffff88000009f000-0xffff880000100000 388K USR RW PWT PCD x pte
> 0xffff880000100000-0xffff880000102000 8K USR RW x pte
> 0xffff880000102000-0xffff880001000000 15352K USR RW x pte
>
> This accounts for all the 4090 pages reported at boot.
I see this same mapping when running Linux 4.9 under either Xen 4.4 or
4.8 (from Debian stable or unstable).
I don't really understand how the PV MMU page tables are set up. I did
try setting the NX flag in make_lowmem_page_readwrite() and that didn't
make any difference to the number of W+X pages.
Ben.
> When booting without Xen, the first 512 MiB is mapped like this:
>
> 0xffff9c2e40000000-0xffff9c2e40097000 604K RW GLB NX pte
> 0xffff9c2e40097000-0xffff9c2e40098000 4K ro GLB NX pte
> 0xffff9c2e40098000-0xffff9c2e40099000 4K ro GLB x pte
> 0xffff9c2e40099000-0xffff9c2e40200000 1436K RW GLB NX pte
> 0xffff9c2e40200000-0xffff9c2e60000000 510M RW PSE GLB NX pmd
>
> (looks like Xen inhibited kASLR too...).
>
> Ben.
>
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#852324: x86/mm: Found insecure W+X mapping
2017-03-16 21:05 ` Bug#852324: x86/mm: Found insecure W+X mapping Ben Hutchings
@ 2017-03-16 21:49 ` Andrew Cooper
2017-03-17 0:18 ` Ben Hutchings
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cooper @ 2017-03-16 21:49 UTC (permalink / raw)
To: Ben Hutchings, 852324, xen-devel
Cc: Boris Ostrovsky, To: Diederik de Haas, Jan Beulich
On 16/03/2017 21:05, Ben Hutchings wrote:
> On Thu, 2017-03-16 at 00:50 +0000, Ben Hutchings wrote:
>> On Wed, 2017-03-15 at 22:24 +0000, Ben Hutchings wrote:
>>> Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
>>> Control: tag -1 upstream confirmed
>>> Control: found -1 4.9.13-1
>>>
>>> I can reproduce this with a current Debian kernel on top of Xen 4.4.
>>> It doesn't happen with the same hardware booting the kernel directly.
>> With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of the
>> low kernel mapping is mapped with W+X permissions, with a few
>> exceptions:
>>
>> 0xffff880000000000-0xffff880000099000 612K USR RW x pte
>> 0xffff880000099000-0xffff88000009a000 4K USR ro NX pte
>> 0xffff88000009a000-0xffff88000009b000 4K USR ro x pte
>> 0xffff88000009b000-0xffff88000009f000 16K USR RW NX pte
>> 0xffff88000009f000-0xffff880000100000 388K USR RW PWT PCD x pte
>> 0xffff880000100000-0xffff880000102000 8K USR RW x pte
>> 0xffff880000102000-0xffff880001000000 15352K USR RW x pte
>>
>> This accounts for all the 4090 pages reported at boot.
> I see this same mapping when running Linux 4.9 under either Xen 4.4 or
> 4.8 (from Debian stable or unstable).
>
> I don't really understand how the PV MMU page tables are set up. I did
> try setting the NX flag in make_lowmem_page_readwrite() and that didn't
> make any difference to the number of W+X pages.
64bit PV guests have some rather special pagetable set up. For one, the
USR bit will be unconditionally set and Xen doesn't tolerate some
mappings being writeable, but these RWX areas are clearly ok in Xens eyes.
Everything from 0xffff880000000000 upwards belongs to the guest kernel
per the PV ABI. The initial layout will be constructed by the domain
builder on behalf of the kernel, but it is Linux's to arbitrarily alter
later on.
Can you boot a debug hypervisor and look at `xl dmesg` starting at the
"*** LOADING DOMAIN 0 ***" line? This should dump the state that the
domain builder leaves dom0 in, which would help identify whether those
regions are leftovers from the domain builder, or something constructed
by the Linux PV early boot code.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#852324: x86/mm: Found insecure W+X mapping
2017-03-16 21:49 ` Andrew Cooper
@ 2017-03-17 0:18 ` Ben Hutchings
2017-03-17 3:05 ` Boris Ostrovsky
0 siblings, 1 reply; 5+ messages in thread
From: Ben Hutchings @ 2017-03-17 0:18 UTC (permalink / raw)
To: Andrew Cooper, 852324, xen-devel
Cc: Boris Ostrovsky, Diederik de Haas, Jan Beulich
[-- Attachment #1.1: Type: text/plain, Size: 5880 bytes --]
On Thu, 2017-03-16 at 21:49 +0000, Andrew Cooper wrote:
> On 16/03/2017 21:05, Ben Hutchings wrote:
> > On Thu, 2017-03-16 at 00:50 +0000, Ben Hutchings wrote:
> > > On Wed, 2017-03-15 at 22:24 +0000, Ben Hutchings wrote:
> > > > Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
> > > > Control: tag -1 upstream confirmed
> > > > Control: found -1 4.9.13-1
> > > >
> > > > I can reproduce this with a current Debian kernel on top of Xen 4.4.
> > > > It doesn't happen with the same hardware booting the kernel directly.
> > >
> > > With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of the
> > > low kernel mapping is mapped with W+X permissions, with a few
> > > exceptions:
> > >
> > > 0xffff880000000000-0xffff880000099000 612K USR RW x pte
> > > 0xffff880000099000-0xffff88000009a000 4K USR ro NX pte
> > > 0xffff88000009a000-0xffff88000009b000 4K USR ro x pte
> > > 0xffff88000009b000-0xffff88000009f000 16K USR RW NX pte
> > > 0xffff88000009f000-0xffff880000100000 388K USR RW PWT PCD x pte
> > > 0xffff880000100000-0xffff880000102000 8K USR RW x pte
> > > 0xffff880000102000-0xffff880001000000 15352K USR RW x pte
> > >
> > > This accounts for all the 4090 pages reported at boot.
> >
> > I see this same mapping when running Linux 4.9 under either Xen 4.4 or
> > 4.8 (from Debian stable or unstable).
> >
> > I don't really understand how the PV MMU page tables are set up. I did
> > try setting the NX flag in make_lowmem_page_readwrite() and that didn't
> > make any difference to the number of W+X pages.
>
> 64bit PV guests have some rather special pagetable set up. For one, the
> USR bit will be unconditionally set and Xen doesn't tolerate some
> mappings being writeable,
I understood that much.
> but these RWX areas are clearly ok in Xens eyes.
So that proves these pages aren't mapped to native page tables or other
sensitive structures, right?
> Everything from 0xffff880000000000 upwards belongs to the guest kernel
> per the PV ABI. The initial layout will be constructed by the domain
> builder on behalf of the kernel, but it is Linux's to arbitrarily alter
> later on.
But it seems to avoid doing that in generic code - see phys_pte_init()
in arch/x86/mm/init_64.c.
> Can you boot a debug hypervisor and look at `xl dmesg` starting at the
> "*** LOADING DOMAIN 0 ***" line? This should dump the state that the
> domain builder leaves dom0 in, which would help identify whether those
> regions are leftovers from the domain builder, or something constructed
> by the Linux PV early boot code.
This is from a hypervisor built with CONFIG_DEBUG=y and everything else
set to defaults (I think):
(XEN) *** LOADING DOMAIN 0 ***
(XEN) ELF: phdr: paddr=0x1000000 memsz=0xac7000
(XEN) ELF: phdr: paddr=0x1c00000 memsz=0x11c000
(XEN) ELF: phdr: paddr=0x1d1c000 memsz=0x193d8
(XEN) ELF: phdr: paddr=0x1d36000 memsz=0x221000
(XEN) ELF: memory: 0x1000000 -> 0x1f57000
(XEN) ELF: note: GUEST_OS = "linux"
(XEN) ELF: note: GUEST_VERSION = "2.6"
(XEN) ELF: note: XEN_VERSION = "xen-3.0"
(XEN) ELF: note: VIRT_BASE = 0xffffffff80000000
(XEN) ELF: note: INIT_P2M = 0x8000000000
(XEN) ELF: note: ENTRY = 0xffffffff81d36180
(XEN) ELF: note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) ELF: note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
(XEN) ELF: note: SUPPORTED_FEATURES = 0x90d
(XEN) ELF: note: PAE_MODE = "yes"
(XEN) ELF: note: LOADER = "generic"
(XEN) ELF: note: unknown (0xd)
(XEN) ELF: note: SUSPEND_CANCEL = 0x1
(XEN) ELF: note: MOD_START_PFN = 0x1
(XEN) ELF: note: HV_START_LOW = 0xffff800000000000
(XEN) ELF: note: PADDR_OFFSET = 0
(XEN) ELF: addresses:
(XEN) virt_base = 0xffffffff80000000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset = 0xffffffff80000000
(XEN) virt_kstart = 0xffffffff81000000
(XEN) virt_kend = 0xffffffff81f57000
(XEN) virt_entry = 0xffffffff81d36180
(XEN) p2m_base = 0x8000000000
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f57000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000214000000->0000000216000000 (1947334 pages to be allocated)
(XEN) Init. ramdisk: 000000021e45a000->000000021f5ff530
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff81f57000
(XEN) Init. ramdisk: 0000000000000000->0000000000000000
(XEN) Phys-Mach map: 0000008000000000->0000008000ef4360
(XEN) Start info: ffffffff81f57000->ffffffff81f574b4
(XEN) Page tables: ffffffff81f58000->ffffffff81f6b000
(XEN) Boot stack: ffffffff81f6b000->ffffffff81f6c000
(XEN) TOTAL: ffffffff80000000->ffffffff82000000
(XEN) ENTRY ADDRESS: ffffffff81d36180
(XEN) Dom0 has maximum 4 VCPUs
(XEN) ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff81ac7000
(XEN) ELF: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81d1c000
(XEN) ELF: phdr 2 at 0xffffffff81d1c000 -> 0xffffffff81d353d8
(XEN) ELF: phdr 3 at 0xffffffff81d36000 -> 0xffffffff81e7f000
(XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) .................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#852324: x86/mm: Found insecure W+X mapping
2017-03-17 0:18 ` Ben Hutchings
@ 2017-03-17 3:05 ` Boris Ostrovsky
2017-03-21 11:36 ` Andrew Cooper
0 siblings, 1 reply; 5+ messages in thread
From: Boris Ostrovsky @ 2017-03-17 3:05 UTC (permalink / raw)
To: Ben Hutchings, Andrew Cooper, 852324, xen-devel
Cc: Jan Beulich, Diederik de Haas
On 03/16/2017 08:18 PM, Ben Hutchings wrote:
> On Thu, 2017-03-16 at 21:49 +0000, Andrew Cooper wrote:
>> On 16/03/2017 21:05, Ben Hutchings wrote:
>>> On Thu, 2017-03-16 at 00:50 +0000, Ben Hutchings wrote:
>>>> On Wed, 2017-03-15 at 22:24 +0000, Ben Hutchings wrote:
>>>>> Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
>>>>> Control: tag -1 upstream confirmed
>>>>> Control: found -1 4.9.13-1
>>>>>
>>>>> I can reproduce this with a current Debian kernel on top of Xen 4.4.
>>>>> It doesn't happen with the same hardware booting the kernel directly.
>>>>
>>>> With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of the
>>>> low kernel mapping is mapped with W+X permissions, with a few
>>>> exceptions:
>>>>
>>>> 0xffff880000000000-0xffff880000099000 612K USR RW x pte
>>>> 0xffff880000099000-0xffff88000009a000 4K USR ro NX pte
>>>> 0xffff88000009a000-0xffff88000009b000 4K USR ro x pte
>>>> 0xffff88000009b000-0xffff88000009f000 16K USR RW NX pte
>>>> 0xffff88000009f000-0xffff880000100000 388K USR RW PWT PCD x pte
>>>> 0xffff880000100000-0xffff880000102000 8K USR RW x pte
>>>> 0xffff880000102000-0xffff880001000000 15352K USR RW x pte
>>>>
>>>> This accounts for all the 4090 pages reported at boot.
>>>
>>> I see this same mapping when running Linux 4.9 under either Xen 4.4 or
>>> 4.8 (from Debian stable or unstable).
>>>
>>> I don't really understand how the PV MMU page tables are set up. I did
>>> try setting the NX flag in make_lowmem_page_readwrite() and that didn't
>>> make any difference to the number of W+X pages.
>>
>> 64bit PV guests have some rather special pagetable set up. For one, the
>> USR bit will be unconditionally set and Xen doesn't tolerate some
>> mappings being writeable,
>
> I understood that much.
>
>> but these RWX areas are clearly ok in Xens eyes.
>
> So that proves these pages aren't mapped to native page tables or other
> sensitive structures, right?
>
>> Everything from 0xffff880000000000 upwards belongs to the guest kernel
>> per the PV ABI. The initial layout will be constructed by the domain
>> builder on behalf of the kernel, but it is Linux's to arbitrarily alter
>> later on.
>
> But it seems to avoid doing that in generic code - see phys_pte_init()
> in arch/x86/mm/init_64.c.
I believe that's because we are reusing pre-built tables which don't
have NX bit set, see xen_setup_kernel_pagetable().
-boris
>
>> Can you boot a debug hypervisor and look at `xl dmesg` starting at the
>> "*** LOADING DOMAIN 0 ***" line? This should dump the state that the
>> domain builder leaves dom0 in, which would help identify whether those
>> regions are leftovers from the domain builder, or something constructed
>> by the Linux PV early boot code.
>
> This is from a hypervisor built with CONFIG_DEBUG=y and everything else
> set to defaults (I think):
>
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) ELF: phdr: paddr=0x1000000 memsz=0xac7000
> (XEN) ELF: phdr: paddr=0x1c00000 memsz=0x11c000
> (XEN) ELF: phdr: paddr=0x1d1c000 memsz=0x193d8
> (XEN) ELF: phdr: paddr=0x1d36000 memsz=0x221000
> (XEN) ELF: memory: 0x1000000 -> 0x1f57000
> (XEN) ELF: note: GUEST_OS = "linux"
> (XEN) ELF: note: GUEST_VERSION = "2.6"
> (XEN) ELF: note: XEN_VERSION = "xen-3.0"
> (XEN) ELF: note: VIRT_BASE = 0xffffffff80000000
> (XEN) ELF: note: INIT_P2M = 0x8000000000
> (XEN) ELF: note: ENTRY = 0xffffffff81d36180
> (XEN) ELF: note: HYPERCALL_PAGE = 0xffffffff81001000
> (XEN) ELF: note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
> (XEN) ELF: note: SUPPORTED_FEATURES = 0x90d
> (XEN) ELF: note: PAE_MODE = "yes"
> (XEN) ELF: note: LOADER = "generic"
> (XEN) ELF: note: unknown (0xd)
> (XEN) ELF: note: SUSPEND_CANCEL = 0x1
> (XEN) ELF: note: MOD_START_PFN = 0x1
> (XEN) ELF: note: HV_START_LOW = 0xffff800000000000
> (XEN) ELF: note: PADDR_OFFSET = 0
> (XEN) ELF: addresses:
> (XEN) virt_base = 0xffffffff80000000
> (XEN) elf_paddr_offset = 0x0
> (XEN) virt_offset = 0xffffffff80000000
> (XEN) virt_kstart = 0xffffffff81000000
> (XEN) virt_kend = 0xffffffff81f57000
> (XEN) virt_entry = 0xffffffff81d36180
> (XEN) p2m_base = 0x8000000000
> (XEN) Xen kernel: 64-bit, lsb, compat32
> (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f57000
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN) Dom0 alloc.: 0000000214000000->0000000216000000 (1947334 pages to be allocated)
> (XEN) Init. ramdisk: 000000021e45a000->000000021f5ff530
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN) Loaded kernel: ffffffff81000000->ffffffff81f57000
> (XEN) Init. ramdisk: 0000000000000000->0000000000000000
> (XEN) Phys-Mach map: 0000008000000000->0000008000ef4360
> (XEN) Start info: ffffffff81f57000->ffffffff81f574b4
> (XEN) Page tables: ffffffff81f58000->ffffffff81f6b000
> (XEN) Boot stack: ffffffff81f6b000->ffffffff81f6c000
> (XEN) TOTAL: ffffffff80000000->ffffffff82000000
> (XEN) ENTRY ADDRESS: ffffffff81d36180
> (XEN) Dom0 has maximum 4 VCPUs
> (XEN) ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff81ac7000
> (XEN) ELF: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81d1c000
> (XEN) ELF: phdr 2 at 0xffffffff81d1c000 -> 0xffffffff81d353d8
> (XEN) ELF: phdr 3 at 0xffffffff81d36000 -> 0xffffffff81e7f000
> (XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
> (XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
> (XEN) .................done.
> (XEN) Initial low memory virq threshold set at 0x4000 pages.
>
> Ben.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#852324: x86/mm: Found insecure W+X mapping
2017-03-17 3:05 ` Boris Ostrovsky
@ 2017-03-21 11:36 ` Andrew Cooper
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Cooper @ 2017-03-21 11:36 UTC (permalink / raw)
To: Boris Ostrovsky, Ben Hutchings, 852324, xen-devel
Cc: Juergen Gross, Jan Beulich, Diederik de Haas
On 17/03/17 03:05, Boris Ostrovsky wrote:
>
>
> On 03/16/2017 08:18 PM, Ben Hutchings wrote:
>> On Thu, 2017-03-16 at 21:49 +0000, Andrew Cooper wrote:
>>> On 16/03/2017 21:05, Ben Hutchings wrote:
>>>> On Thu, 2017-03-16 at 00:50 +0000, Ben Hutchings wrote:
>>>>> On Wed, 2017-03-15 at 22:24 +0000, Ben Hutchings wrote:
>>>>>> Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
>>>>>> Control: tag -1 upstream confirmed
>>>>>> Control: found -1 4.9.13-1
>>>>>>
>>>>>> I can reproduce this with a current Debian kernel on top of Xen 4.4.
>>>>>> It doesn't happen with the same hardware booting the kernel
>>>>>> directly.
>>>>>
>>>>> With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of
>>>>> the
>>>>> low kernel mapping is mapped with W+X permissions, with a few
>>>>> exceptions:
>>>>>
>>>>> 0xffff880000000000-0xffff880000099000 612K USR
>>>>> RW x pte
>>>>> 0xffff880000099000-0xffff88000009a000 4K USR
>>>>> ro NX pte
>>>>> 0xffff88000009a000-0xffff88000009b000 4K USR
>>>>> ro x pte
>>>>> 0xffff88000009b000-0xffff88000009f000 16K USR
>>>>> RW NX pte
>>>>> 0xffff88000009f000-0xffff880000100000 388K USR RW PWT
>>>>> PCD x pte
>>>>> 0xffff880000100000-0xffff880000102000 8K USR
>>>>> RW x pte
>>>>> 0xffff880000102000-0xffff880001000000 15352K USR
>>>>> RW x pte
>>>>>
>>>>> This accounts for all the 4090 pages reported at boot.
>>>>
>>>> I see this same mapping when running Linux 4.9 under either Xen 4.4 or
>>>> 4.8 (from Debian stable or unstable).
>>>>
>>>> I don't really understand how the PV MMU page tables are set up. I
>>>> did
>>>> try setting the NX flag in make_lowmem_page_readwrite() and that
>>>> didn't
>>>> make any difference to the number of W+X pages.
>>>
>>> 64bit PV guests have some rather special pagetable set up. For one,
>>> the
>>> USR bit will be unconditionally set and Xen doesn't tolerate some
>>> mappings being writeable,
>>
>> I understood that much.
>>
>>> but these RWX areas are clearly ok in Xens eyes.
>>
>> So that proves these pages aren't mapped to native page tables or other
>> sensitive structures, right?
>>
>>> Everything from 0xffff880000000000 upwards belongs to the guest kernel
>>> per the PV ABI. The initial layout will be constructed by the domain
>>> builder on behalf of the kernel, but it is Linux's to arbitrarily alter
>>> later on.
>>
>> But it seems to avoid doing that in generic code - see phys_pte_init()
>> in arch/x86/mm/init_64.c.
>
>
> I believe that's because we are reusing pre-built tables which don't
> have NX bit set, see xen_setup_kernel_pagetable().
Right, in which case the W+X warning is entirely correct and pointing
out a security weakness.
The domain builder can't usefully know exactly how Linux wants its NX
and RO mappings at boot, particularly if the init code wants to rely on
things being RW to start with.
xen_setup_kernel_pagetable() should be altered to make suitable
permission alterations to the provided initial pagetables.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-03-21 11:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1489616679.2852.28.camel@decadent.org.uk>
[not found] ` <1489625430.2852.30.camel@decadent.org.uk>
2017-03-16 21:05 ` Bug#852324: x86/mm: Found insecure W+X mapping Ben Hutchings
2017-03-16 21:49 ` Andrew Cooper
2017-03-17 0:18 ` Ben Hutchings
2017-03-17 3:05 ` Boris Ostrovsky
2017-03-21 11:36 ` Andrew Cooper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.