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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel