Re: [Xen-devel] XSM instead of IS_PRIV

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 07/28/2012 10:54 AM, Shakeel Butt wrote:
> Are there any plans to replace IS_PRIV altogether with corresponding
> XSM hooks? There was an old discussion (in 2007) on the mailing list
> on similar issue and it was proposed that IS_PRIV should be replaced
> with XSM hooks. Now still IS_PRIV is being used in latest xen-unstable
> branch. So, is there a reason to keep using IS_PRIV?
> 
> thanks,
> Shakeel
> 

I have a patch starting this change, which I had been planning to finish
and post after 4.3 branches. It makes the majority of IS_PRIV calls depend
on !define(XSM_ENABLE) and changes the dummy XSM module hooks to preserve
the semantics of XSM being disabled at compile time. It doesn't currently
cover every IS_PRIV call (hardware access is mostly not covered) or most
of the IS_PRIV_FOR calls. However, it does allow xl to be used in a domU
to manage other domains (list, pause, destroy, etc) and only xenstore
permission issues need to be resolved in order to do things like add
block/network devices.

Once this is done, it will make sense to change the XSM header file so
that the appropriate xsm_* hooks resolve to IS_PRIV when XSM is not
enabled. This would allow the IS_PRIV hooks covered by XSM to be
completely removed, assuming the Xen developers agree that the XSM hooks
cover all all the important code. Some, such as the create domain hook,
are deep enough in the calling code that callers getting permission denied
might be able to cause issues by e.g. rolling over the new domain ID counter.

-- 
Daniel De Graaf
National Security Agency

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