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
next prev parent 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).