Re: [Xen-devel] Bug#852324: x86/mm: Found insecure W+X mapping

[Ben Hutchings <ben@xxxxxxxxxxxxxxx>]

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: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel