Re: [patch] validate binary before use

[Aleksandar Ristovski <aristovski@qnx.com>]

On 13-04-04 04:13 AM, Jan Kratochvil wrote:
> On Thu, 04 Apr 2013 04:03:43 +0200, Aleksandar Ristovski wrote:
>> Actually, as I think about this more, we can not use section from
>> possibly unrelated bfd to read build-id in native debugging case. At
>> a minimum, we can not store such build-id as abfd may not even
>> relate to what's in target's memory.
>
> Why?
>
> If the target shared library does not match then GDB will read some random
> memory.  The target shared library may not even have any build-id.
>
> As the build-id has 160 bits there is 1:2^160 probability of a false positive,
> that is safe enough.

The problem is, we could 'remember' build-id that is garbage. I will add 
checking for GNU\0 and note type, and then the likelihood that somewhat 
random memory will match namesz, name and type will be very low (though 
the likelihood has nothing to do with the 160 bits of build-id; build-id 
is not necessarily 160 bits either).

The rest of the e-mail applies:

>
>
>> The chunk of code that is in svr4_relocate_section_addresses in the
> you probably mean              solib_map_sections
>
>> latest version of the patch needs to go back to svr4_validate, and
>> not store build-id.
>
>
> I do not understand this whole mail, it would be best to provide a countercase
> where the current patchset does not behave correctly.


The above should explain why is current patchset incorrect (in 
particular patch #7).

The rest is about design and duplicated functionality. The functionality 
of gdbserver where it fetches the list is exactly the same what -nat can 
do; in fact this could be the same code; and then solib-svr4.c deals 
only with TARGET_OBJECT_LIBRARIES_SVR4. The infrastructure is in place.

Impact on solib-svr4.c: svr4_validate would be exactly as it is now, 
simply check. svr4_relocate_section_addresses would not need the kludge 
for reading build-id, there would be only one path of getting build-id.

Not to be neglected is that by doing so, it would be possible to look 
for the debug binary directly, by using build-id instead of opening 
objfile and then looking for separate_debug_fie.


---
Aleksandar