[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v1] Add build-id to XENVER hypercall.



>>> On 29.10.15 at 20:47, <konrad.wilk@xxxxxxxxxx> wrote:
> On Thu, Oct 29, 2015 at 02:55:25AM -0600, Jan Beulich wrote:
>> >>> On 28.10.15 at 20:00, <konrad.wilk@xxxxxxxxxx> wrote:
>> > @@ -302,9 +315,14 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
>> > arg)
>> >          if ( copy_from_guest(&fi, arg, 1) )
>> >              return -EFAULT;
>> >  
>> > +        if ( empty_data )
>> > +            memset(&fi, 0, sizeof(fi));
>> > +
>> >          switch ( fi.submap_idx )
>> >          {
>> >          case 0:
>> > +            if ( empty_data )
>> > +                break;
>> >              fi.submap = (1U << XENFEAT_memory_op_vnode_supported);
>> >              if ( VM_ASSIST(d, pae_extended_cr3) )
>> >                  fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb);
>> 
>> This one, afaict, is _specifically_ meant to be available to everyone.
> 
> OK, so we go back to that some of the subops should _not_ be behind
> an XSM check as they are meant to be available to everyone.
> 
> Or rather - there is no point of an XSM check at all for those.

Yes - excluding certain sub-ops from being always accessible should
be the exception (i.e. where truly warranted by security
considerations). Only in those cases would I view it as appropriate
to return e.g. blank strings instead of the previous valid data.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.