>>> On 08.01.16 at 18:31, <konrad.w...@oracle.com> wrote: >> >> > The rest: XENVER_[version|capabilities| >> >> > parameters|get_features|page_size|guest_handle] behave >> >> > as before - allowed by default for all guests. >> >> > >> >> > This is with the XSM default policy and with the dummy ones. >> >> >> >> And with a non-default policy you now ignore one of the latter >> >> ops to also get denied. >> > >> > No, but that is due to the 'deny' being only checked for certain subops. >> >> To me this reply seems contradictory in itself: The "no" doesn't >> seem to match up with the rest. >> >> > I think what you are saying is that for XENVER_[version|capabilities| >> > parameters|get_features|page_size|guest_handle] we should not have any >> > XSM checks as they serve no purpose (which is what I had in the earlier >> > versions of this patch). However Andrew mentioned that he would >> > like _ALL_ of the sub-ops to be checked for. >> >> And I agree with Andrew, hence my earlier comment above (with >> the reply I can't really make sense of). > > I am all confused now. > > There are two parts here: > a) The XSM checks - which allow the XENVER_version..XENVER_guest_handle > without any hinderance. For XENVER_commandline and XENVER_buildid > they are evaluated. > > b) Acting on the XSM check. For most of them we cannot actually return > -EFAULT and MUST return either an valid value or some form of a string. > > The ones for which we could return '<denied>' were changeset, compile_info, > commandline, extraversion. To make it simpler we only do it for > commandline. > > In essence we have an XSM check which is ignored by all XENVER_ subops > except commandline (and build_id in later patch). > > I think both of you are OK with that?
Iirc Andrew's request was to honor XSM denies on any sub-op when a non-default policy is in place. Whereas in default mode only command line and build id are the ones clearly needing restricting. Which won't be possible if you ignore the return value of the XSM check in some of the cases. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
