|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap permissions
On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>> When a domain is mapping pages from a different pg_owner domain, the
>> iomem_access checks are currently only applied to the pg_owner domain,
>> potentially allowing the current domain to bypass its more restrictive
>> iomem_access policy using another domain that it has access to.
>
> Are you sure about this? I ask because ...
>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>> return -EINVAL;
>> }
>>
>> + if ( pg_owner != curr->domain &&
>> + !iomem_access_permitted(curr->domain, mfn, mfn) )
>> + {
>> + if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>> + {
>> + MEM_LOG("Domain %u attempted to map I/O space %08lx in
>> domain %u",
>> + curr->domain->domain_id, mfn, pg_owner->domain_id);
>> + return -EPERM;
>> + }
>> + return -EINVAL;
>> + }
>> +
>
> ... the place you insert this is after non-RAM pages got filtered
> out already, so you're applying an IOMEM permission check to a
> RAM page.
>
> Jan
>
>> if ( !(l1f & _PAGE_RW) ||
>> !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>> return 0;
If that's true, then the check a few lines above is also applying IOMEM
checks to RAM pages. I can see non-privileged attempts being filtered
above, but successful mappings will continue to the check I added.
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |