On 05/30/2017 08:50 AM, Pavel Hrdina wrote:
> On Tue, May 30, 2017 at 07:38:16AM -0400, John Ferlan wrote:
>> The virObject logic "assumes" that whatever is passed to its API's
>> would be some sort of virObjectPtr; however, if it is not then some
>> really bad things can happen.
>>
>> So far there's been only virObject{Ref|Unref}, virObject{Lock|Unlock},
>> and virObjectIsClass and the virObject and virObjectLockable class
>> consumers have been well behaved and code well tested. Soon there will
>> be more consumers and one such consumer tripped over this during testing
>> by passing a virHashTablePtr to virObjectIsClass which ends up calling
>> virClassIsDerivedFrom using "obj->klass", which wasn't really a klass
>> object causing one of those bad things to happen.
>>
>> To avoid the future possibility that a non virObject class memory was
>> passed to some virObject* API, let's add a "magic_marker" to the base
>> virObject class that contains a value "0xFEEDBEEF", then any place in
>> the code which would accept or process the base opaque virObjectPtr,
>> compare the magic_marker against 0xFEEDBEEF to make sure this is an
>> object allocated by this code.
>>
>> It is still left up to the caller to handle the failed API calls just
>> as it would be if it passed a NULL opaque pointer anyobj.
>
> I don't think that we need to guard this kind of programming error.
> We've been able to cope with the current virObject code without hitting
> this issue.
>
I don't disagree that we've been able to cope, but adding more objects
makes things more interesting and prone to having code trip across a bad
usage which we could have prevented. The base object classes make a lot
of assumptions and use opaque params, so having some sort of check
prevents those possibly very bad things happening. Not everyone is well
behaved and at times we do make assumptions. IIRC it took me a bit of
combing through what I'd changed to figure out my erroneous usage which
resulted in me adding this to make it very much so more obvious.
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
