All of lore.kernel.org
 help / color / mirror / Atom feed
From: anshul makkar <anshul.makkar@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, cardoe@cardoe.com
Subject: Re: default XSM policy for PCI passthrough for unlabeled resources.
Date: Wed, 6 Jul 2016 17:19:15 +0100	[thread overview]
Message-ID: <577D2F83.7000103@citrix.com> (raw)
In-Reply-To: <6be3e7fc-f3c6-8c9c-39fb-0c1c1d9a4389@tycho.nsa.gov>

On 06/07/16 16:59, Daniel De Graaf wrote:
> On 07/06/2016 11:34 AM, anshul makkar wrote:
>> Hi,
>>
>>
>> It allows the resource to be added and removed by the source domain to
>> target domain, but its use by target domain is blocked.
>
> This rule only mandates the use of resource_type for resource types.  If
> you are creating a new resource type, follow the example in nic_dev.te.
Agreed, but inherently it means that "use" of any unlabeled resource be 
it irq, ioport or iomem or nic_dev is restricted.
>
>> The resource can be used only if it has been labeled using
>> flask-label-pci command which needs to be rerun after every boot and
>> after every policy reload.
>
> Yes; this gives the most control over what resources can be delegated.
> Policy reloads are supposed to be rare (on a production system) and you
> already need special boot scripts (or parameters) to set up the device
> for passthrough, so this can be added there.  However, I agree this can
> be more work than a "default" FLASK policy should require.
>
> Try adding a module with the following rules, which should allow domU to
> use unlabeled devices:
>
> use_device(domU_t, irq_t)
> use_device(domU_t, ioport_t)
> use_device(domU_t, iomem_t)
> use_device(domU_t, device_t)
Yes, it does work , but I have added these in delegate_device to make it 
restrict to the case where there is delegation.
>
> If this works, that module could be added to the default policy.
>
>> Given that what we ship is just a sample default policy for reference
>> which is expected to be permissive in most of the scenarios so that it
>> doesn't affect the basic functionalities, is this "neverallow" rule
>> needed ?
>>
>> Thanks
>> Anshul Makkar
>
> The neverallow rules are just there to ensure that the attributes are
> being used correctly.
>
Anshul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-07-06 16:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-23 15:05 [PATCH 0/5] flask/policy: Updates for Xen 4.8 Daniel De Graaf
2016-05-23 15:05 ` [PATCH 1/5] flask/policy: split into modules Daniel De Graaf
2016-06-07 19:22   ` Konrad Rzeszutek Wilk
2016-06-07 19:39     ` Daniel De Graaf
2016-06-07 19:57       ` Konrad Rzeszutek Wilk
2016-05-23 15:05 ` [PATCH 2/5] flask/policy: move user definitions and constraints " Daniel De Graaf
2016-06-07 19:37   ` Konrad Rzeszutek Wilk
2016-05-23 15:05 ` [PATCH 3/5] flask/policy: Remove unused support for binary modules Daniel De Graaf
2016-06-07 19:41   ` Konrad Rzeszutek Wilk
2016-05-23 15:05 ` [PATCH 4/5] flask/policy: xenstore stubdom policy Daniel De Graaf
2016-06-07 19:44   ` Konrad Rzeszutek Wilk
2016-06-07 19:48     ` Daniel De Graaf
2016-06-07 20:02       ` Konrad Rzeszutek Wilk
2016-07-06 15:34   ` default XSM policy for PCI passthrough for unlabeled resources anshul makkar
2016-07-06 15:59     ` Daniel De Graaf
2016-07-06 16:19       ` anshul makkar [this message]
2016-07-07 15:36         ` Daniel De Graaf
2016-07-07 16:29           ` anshul makkar
2016-05-23 15:05 ` [PATCH 5/5] flask/policy: comment out unused xenstore example Daniel De Graaf
2016-06-07 19:45   ` Konrad Rzeszutek Wilk
2016-06-07 19:51     ` Daniel De Graaf
2016-06-07 20:02       ` Konrad Rzeszutek Wilk
2016-06-07 20:04         ` Daniel De Graaf

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=577D2F83.7000103@citrix.com \
    --to=anshul.makkar@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.