From: Daniel De Graaf <firstname.lastname@example.org> To: anshul makkar <email@example.com>, firstname.lastname@example.org Cc: email@example.com, firstname.lastname@example.org Subject: Re: default XSM policy for PCI passthrough for unlabeled resources. Date: Wed, 6 Jul 2016 11:59:05 -0400 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <577D24FE.firstname.lastname@example.org> On 07/06/2016 11:34 AM, anshul makkar wrote: > Hi, > > Default XSM policy doesn't allow the use of unlabeled PCI resources that have been passed through to target domain. > > xen.te > # Resources must be declared using . resource_type > neverallow * ~resource_type:resource use; > > 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. > 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. > The above approach reduces the flexibility and necessitates admin intervention to give passthrough rights after host has booted. Also, in general if I want to allow all domUs to have PCI passthough access to all PCI device, I have no other way apart from disabling the "neverallow" rule. 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) 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. -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xenemail@example.com https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-07-06 15:59 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 [this message] 2016-07-06 16:19 ` anshul makkar 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: default XSM policy for PCI passthrough for unlabeled resources.' \ /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
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).