|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |