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

[Martin Pohlack <mpohlack@xxxxxxxxxx>]

On 14.08.2015 15:54, Jan Beulich wrote:
>>>> 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?

Sorry about that, my (not expressed) thinking was that we should
restrict that to Dom0 for the XSM-disabled case.

>>>> @@ -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
> 

Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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