xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Arianna Avanzini <avanzini.arianna@gmail.com>
Cc: julien.grall@citrix.com, paolo.valente@unimore.it, keir@xen.org,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	dario.faggioli@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	etrudeau@broadcom.com, JBeulich@suse.com,
	andrew.cooper3@citrix.com, viktor.kleinik@globallogic.com,
	andrii.tseglytskyi@globallogic.com
Subject: Re: [PATCH v12 11/14] flask/policy: allow domU to use previously-mapped I/O-memory
Date: Wed, 03 Sep 2014 10:45:18 -0400	[thread overview]
Message-ID: <5407297E.2080202@tycho.nsa.gov> (raw)
In-Reply-To: <1409743296.22712.10.camel@eu.citrix.com>

On 09/03/2014 07:21 AM, Ian Campbell wrote:
> On Sat, 2014-08-30 at 18:29 +0200, Arianna Avanzini wrote:
>> From: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
>>
>> This commit allows the domU to access previously-mapped I/O-memory
>> even if XSM is enabled and FLASK is enforced.
>
> CCing Daniel (XSM maintainer).
>
> I think this is probably OK, but I'm no XSM expert.
>
> (If I were writing the ocmmit message I would have said something like
> "Update the example XSM policy to allow...")

The message Ian suggests is a bit clearer as to the effect of the patch.

Regarding the patch: at minimum, a domU should only need the permissions
defined by "use_device(domU_t, iomem_t)" to access mapped memory.  However,
it is preferred to label the IO memory being used instead of allowing access
to the default/fallback iomem_t.

The intention for handing pass-through devices with FLASK is to label the
device (either using the tool flask-label-pci or manually in the policy;
example lines for the latter are present and commented out).  The example
policy defines the type nic_dev_t as a device that is usable by domU_t, and
docs/misc/xsm-flask.txt has an example of flask-label-pci's use.

If you are actually only passing IO memory and not a PCI device, labeling
the IO memory range would be the preferred solution.  If you cannot label
it statically, a tool similar to flask-label-pci for memory will be needed -
something like "flask-label-resource <type> <start>-<end> <label>".  This
may be more common on ARM than on x86; I am not familiar with pass-through
on ARM, and the only non-PCI device on x86 that I have used pass-through on
is the TPM, which has a well-defined IO memory range.

-- 
Daniel De Graaf
National Security Agency

  reply	other threads:[~2014-09-03 14:45 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-30 16:29 [PATCH v12 00/14] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 01/14] arch/arm: add consistency check to REMOVE p2m changes Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 02/14] arch/arm: unmap partially-mapped memory regions Arianna Avanzini
2014-09-01 17:53   ` Julien Grall
2014-09-01 20:13     ` Arianna Avanzini
2014-09-01 23:47     ` [PATCH] " Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 03/14] arch/x86: warn if to-be-removed mapping does not exist Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 04/14] arch/x86: cleanup memory_mapping DOMCTL Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 05/14] xen/common: add ARM stub for the function memory_type_changed() Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 06/14] xen/x86: factor out map and unmap from the memory_mapping DOMCTL Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 07/14] xen/common: move the memory_mapping DOMCTL hypercall to common code Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 08/14] tools/libxl: parse optional start gfn from the iomem config option Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 09/14] tools/libxl: handle the iomem parameter with the memory_mapping hcall Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 10/14] xsm/flask: avoid spurious error messages when mapping I/O-memory Arianna Avanzini
2014-09-03 11:22   ` Ian Campbell
2014-09-03 11:30     ` Ian Campbell
2014-09-03 14:41   ` Daniel De Graaf
2014-09-04 11:49     ` [PATCH] xsm/flask: handle XEN_DOMCTL_memory_mapping for all architectures Arianna Avanzini
2014-09-08 10:11       ` Ian Campbell
2014-09-08 12:24         ` Arianna Avanzini
2014-09-08 12:38           ` Ian Campbell
2014-09-08 12:50             ` Arianna Avanzini
2014-09-09 12:35               ` Ian Campbell
2014-09-09 13:13                 ` Arianna Avanzini
2014-09-09 14:45                   ` Ian Campbell
2014-09-10 20:07                     ` Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 11/14] flask/policy: allow domU to use previously-mapped I/O-memory Arianna Avanzini
2014-09-03 11:21   ` Ian Campbell
2014-09-03 14:45     ` Daniel De Graaf [this message]
2014-09-05 23:25       ` Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 12/14] tools/libxl: explicitly grant access to needed I/O-memory ranges Arianna Avanzini
2014-09-03 11:26   ` Ian Campbell
2014-09-08 15:05     ` [PATCH 0/3] Separate the functions of the memory_mapping and iomem_permission DOMCTLs Arianna Avanzini
2014-09-08 15:05       ` [PATCH 1/3] tools/libxl: explicitly grant access to needed I/O-memory ranges Arianna Avanzini
2014-09-08 15:05       ` [PATCH 2/3] tools/libxl: cleanup the do_pci_add() function Arianna Avanzini
2014-09-08 15:05       ` [PATCH 3/3] xen/common: do not implicitly permit access to mapped I/O memory Arianna Avanzini
2014-08-30 16:29 ` [PATCH v12 13/14] tools/libxl: cleanup the do_pci_add() function Arianna Avanzini
2014-09-03 11:27   ` Ian Campbell
2014-08-30 16:29 ` [PATCH v12 14/14] xen/common: do not implicitly permit access to mapped I/O memory Arianna Avanzini
2014-09-03 12:15 ` [PATCH v12 00/14] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM Ian Campbell
2014-09-03 13:55   ` Arianna Avanzini

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=5407297E.2080202@tycho.nsa.gov \
    --to=dgdegra@tycho.nsa.gov \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=andrii.tseglytskyi@globallogic.com \
    --cc=avanzini.arianna@gmail.com \
    --cc=dario.faggioli@citrix.com \
    --cc=etrudeau@broadcom.com \
    --cc=julien.grall@citrix.com \
    --cc=keir@xen.org \
    --cc=paolo.valente@unimore.it \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=viktor.kleinik@globallogic.com \
    --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).