xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH 19/22] arch/x86: check remote MMIO remap permissions
Date: Thu, 13 Sep 2012 12:46:55 -0400	[thread overview]
Message-ID: <50520DFF.4030505@tycho.nsa.gov> (raw)
In-Reply-To: <5052121F020000780009B1E9@nat28.tlf.novell.com>

On 09/13/2012 11:04 AM, Jan Beulich wrote:
>>>> On 13.09.12 at 16:25, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/13/2012 10:13 AM, Jan Beulich wrote:
>>>>>> On 13.09.12 at 15:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> 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,
>>
>> "above" refers to "if ( !iomem_access_permitted(pg_owner, mfn, mfn) )"
>>  
>>> I can't see how that would happen given this primary conditional
>>>
>>>     if ( !mfn_valid(mfn) ||
>>>          (real_pg_owner = page_get_owner_and_reference(page)) == dom_io )
>>>
>>> Please clarify what you're observing.
>>
>> As I understand it, the contents of this block will be executed if the MFN 
>> is
>> invalid (interpreted as MMIO space) or if the page's owner is DOMID_IO, 
>> which
>> is how MMIO space is marked.
>>
>>>> but successful mappings will continue to the check I added.
>>>
>>> Of course. I would think that if anything, you would want to add
>>> a second call to iomem_access_permitted() with "curr->domain"
>>> right at the place where the current one is (in particular inside
>>> the above quoted conditional).
>>>
>>> Jan
>>
>> I was emulating the existing iomem_access_permitted check being run on 
>> pg_owner;
>> moving the curr->domain check up into this first conditional would end up
>> treating the MMIO mapping as a regular RAM mapping if the 
>> iomem_access_permitted
>> fails. Unless you're talking about a different quoted conditional?
> 
> I'm sorry, each of your replies get me more confused. Can you,
> with the current code (i.e. without your patches or any emulation
> you might be doing) explain (perhaps with an example) what
> specific case you see needing more checking than there is
> currently? That would probably allow us to start talking about the
> same thing.
> 
> Jan
> 

For this example, assume domain A has access to map domain B's memory
read-only. Domain B has access to a device with MMIO where reads to the
device's memory cause state changes - an example of such as device is a
TPM, where replies are read by repeated reads to a single 4-byte 
address. Domain A does not have access to this device, and would like to
maliciously interfere with the device.

If domain A maps the MMIO page from domain B using pg_owner == domB, the
iomem_access_permitted check will be done from domain B's perspective. 
While this is needed when domain A is mapping pages on behalf of domB, 
it is not sufficient when attempting to constrain domain A's access. 

These checks only apply to MMIO, so the condition on line 735 will
evaluate to true (!mfn_valid || real_pg_owner == dom_io).

The (existing) check on domain B's MMIO access is:
        if ( !iomem_access_permitted(pg_owner, mfn, mfn) )

This patch adds a check on domain A:
        if ( !iomem_access_permitted(curr->domain, mfn, mfn) )
            
This extra checking has not been required without XSM because only FLASK
implements the ability to grant one domain read-only access to another 
domain. With read-write access, this extra access check is simple to get
around: domain A can modify some part of the executable code in domain B
to act as a proxy for its accesses. Additionally, domain A is usually
dom0 or the device model, which have equal or greater MMIO access.

-- 
Daniel De Graaf
National Security Agency

  reply	other threads:[~2012-09-13 16:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-12 15:59 [PATCH v3] Merge IS_PRIV checks into XSM hooks Daniel De Graaf
2012-09-12 15:59 ` [PATCH 01/22] xsm/flask: remove inherited class attributes Daniel De Graaf
2012-09-12 15:59 ` [PATCH 02/22] xsm/flask: remove unneeded create_sid field Daniel De Graaf
2012-09-12 15:59 ` [PATCH 03/22] xen: Add versions of rcu_lock_*_domain without IS_PRIV checks Daniel De Graaf
2012-09-12 15:59 ` [PATCH 04/22] xsm/flask: add domain relabel support Daniel De Graaf
2012-09-12 15:59 ` [PATCH 05/22] libxl: introduce XSM relabel on build Daniel De Graaf
2012-09-12 15:59 ` [PATCH 06/22] flask/policy: Add domain relabel example Daniel De Graaf
2012-09-12 15:59 ` [PATCH 07/22] arch/x86: add distinct XSM hooks for map/unmap Daniel De Graaf
2012-09-12 15:59 ` [PATCH 08/22] xsm/flask: Add checks on the domain performing the set_target operation Daniel De Graaf
2012-09-12 15:59 ` [PATCH 09/22] xsm: Use the dummy XSM module if XSM is disabled Daniel De Graaf
2012-09-13  7:46   ` Jan Beulich
2012-09-13 13:40     ` Daniel De Graaf
2012-09-12 15:59 ` [PATCH 10/22] xen: use XSM instead of IS_PRIV where duplicated Daniel De Graaf
2012-09-12 15:59 ` [PATCH 11/22] xen: avoid calling rcu_lock_*target_domain when an XSM hook exists Daniel De Graaf
2012-09-12 15:59 ` [PATCH 12/22] arch/x86: convert platform_hypercall to use XSM Daniel De Graaf
2012-09-12 15:59 ` [PATCH 13/22] xen: lock target domain in do_domctl common code Daniel De Graaf
2012-09-12 15:59 ` [PATCH 14/22] xen: convert do_domctl to use XSM Daniel De Graaf
2012-09-12 15:59 ` [PATCH 15/22] xen: convert do_sysctl " Daniel De Graaf
2012-09-12 15:59 ` [PATCH 16/22] xsm/flask: add missing hooks Daniel De Graaf
2012-09-12 15:59 ` [PATCH 17/22] xsm/flask: add distinct SIDs for self/target access Daniel De Graaf
2012-09-12 15:59 ` [PATCH 18/22] arch/x86: Add missing mem_sharing XSM hooks Daniel De Graaf
2012-09-12 15:59 ` [PATCH 19/22] arch/x86: check remote MMIO remap permissions Daniel De Graaf
2012-09-13  8:00   ` Jan Beulich
2012-09-13 13:46     ` Daniel De Graaf
2012-09-13 14:13       ` Jan Beulich
2012-09-13 14:25         ` Daniel De Graaf
2012-09-13 15:04           ` Jan Beulich
2012-09-13 16:46             ` Daniel De Graaf [this message]
2012-09-14  8:54               ` Jan Beulich
2012-09-14 13:37                 ` Daniel De Graaf
2012-09-14 14:21                   ` Jan Beulich
2012-09-12 15:59 ` [PATCH 20/22] arch/x86: use XSM hooks for get_pg_owner access checks Daniel De Graaf
2012-09-13  8:13   ` Jan Beulich
2012-09-13 13:55     ` Daniel De Graaf
2012-09-13 14:15       ` Jan Beulich
2012-09-12 15:59 ` [PATCH 21/22] xen: Add XSM hook for XENMEM_exchange Daniel De Graaf
2012-09-12 15:59 ` [PATCH 22/22] tmem: add XSM hooks Daniel De Graaf
2012-09-13 14:37 ` [PATCH v3] Merge IS_PRIV checks into " Ian Jackson
2012-09-13 15:08   ` Daniel De Graaf
2012-09-13 15:29     ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50520DFF.4030505@tycho.nsa.gov \
    --to=dgdegra@tycho.nsa.gov \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).