Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.08.15 at 14:59, <mpohlack@xxxxxxxxxx> wrote:
> On 11.08.2015 16:12, Jan Beulich wrote:
>>>>> On 05.08.15 at 16:09, <mpohlack@xxxxxxxxx> wrote:
>>> Todo:
>>>   * Should be moved to sysctl to only allow Dom0 access
>> 
>> Because of?
> 
> The discussion in this thread:
> 
> [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
> 
> was:
> ----------------------------------------------------------------------
>>> Martin Pohlack:
>>> We should not expose the build_id to normal guests, but only to Dom0.
>>>
>>> A build_id uniquely identifies a specific build and I don't see how that
>>> information would be required from DomU.  It might actually help an
>>> attacker to build his return-oriented programming exploit against a
>>> specific build.
>>>
>>> The normal version numbers should be enough to know about capabilities
>>> and API.
>>
>> Andrew Cooper:
>> 
>> It will need its own XSM hook, but need not be strictly limited to just
>> dom0.
> ----------------------------------------------------------------------

So I'm confused - I asked "why Dom0 only" and then you point me to
Andrew saying it doesn't need to be Dom0 only?

>>> @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
>>> arg)
>>>  
>>>      case XENVER_build_id:
>>>      {
>>> -        xen_build_id_t build_id;
>>> +        xen_build_id_t ascii_id;
>>> +        Elf_Note * n = (Elf_Note *)&__note_gnu_build_id_start;
>>> +        char * binary_id;
>>> +        int i;
>>> +
>>> +        memset(ascii_id, 0, sizeof(ascii_id));
>>> +
>>> +        /* check if we really have a build-id */
>>> +        if ( NT_GNU_BUILD_ID != n->type )
>>> +            return 0;
>> 
>> This needs to signal an error.
> 
> Yes, ENOSYS, (or ENOENT, ENODATA)?

Definitely not ENOSYS. ENODATA or EOPNOTSUPP.

Jan


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