I should add the xsm=policy option to the end of the xen.cfg instead of as
an option. Sorry for the fault.
However, another problem is that when I modified the policy and reload it
using '*xl loadpolicy*', the policy seemed not working.
The policy I add is *'allow domU_t security_t:security check_context; allow
domU_t domU_t_self:hvm gethvmc;*', and it is successfully loaded.
But executing XEN_DOMCTL_gethvmcontext_partial in domU_t would still cause
the following violations:
*(XEN) avc: denied { gethvmc } for domid=1
scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
tclass=hvm*
Rebooting xen with the new policy doesn't work too. BTW, the domU_t I
created is a HVM, I hope that is not the problem.
2016-05-17 16:33 GMT+08:00 Jan Beulich <jbeul...@suse.com>:
> >>> On 16.05.16 at 17:00, <fangtu...@gmail.com> wrote:
> > Actually I did that, but the policy is not loaded at all. 'xl list -Z'
> show
> > no lable on guests. It seems like that the option 'xsm=xen-policy-4.6.0'
> is
> > ingnored during booting. (the policy file is moved to the same directory
> as
> > xen.cfg)
>
> If you suspect it to be ignored, then please provide logs so we
> can identify _where_ it gets ignored: The early EFI loader should
> be pulling it into memory (note that the respective messages will
> only be visible in a serial log if you also enable serial output for
> EFI itself), and then XSM should be consuming it. Which of the
> two goes wrong would be quite helpful to know, the more that it
> looks like this works for others (e.g. Konrad).
>
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
