[Spice-devel] [PATCH 1/2] Ensure that plugins cannot bypass version check

[Christophe de Dinechin]

> On 20 Apr 2018, at 12:51, Christophe Fergeau <cfergeau at redhat.com> wrote:
> 
> On Fri, Apr 20, 2018 at 10:10:17AM +0200, Christophe de Dinechin wrote:
>> There is no easy way to test if a method is there. There is, however,
>> an easy way to test if a C entry point is there in a shared library.
>> This is the difference between your scenario and mine. In mine, I can
>> explicitly test if the new C entry point is there, and since it has
>> been added, I know the plugin is aware of the new semantics. So I can
>> then decide to remove the old entry point later, and then I know that
>> a version 13 plugin that has the new entry point follows that new
>> semantics (in the example I gave, that it knows how to unload).
> 
> We introduce the new entry point in version 13, let's say we deprecate
> the old semantics at the same time. We can have plugins which switched
> to the new semantics, and are built against version 13. We can also have
> plugins which still follow the old semantics, and they will still work.
> I assume these plugins following the old semantics could be rebuilt
> against version 13? And that we can have a plugin with ABI 13 following
> the old semantics?

Yes, these will expose only the old entry point.


> Then in 21, we remove support for the old semantics, and we say that we
> still support plugins starting from ABI 13. But what about that plugin
> following the old semantics that we rebuilt against ABI 13?

That plugin would only expose the old entry point, so it would no longer load after version 21. This is why we moved the cursor of “oldest compatible” to 13: anything older than that we know will not load, since it does not have the new entry point. But we still have the capability to reject a plugin (in a well defined, non-crashing way) for other reasons.

Imagine another scenario where we add capabilities. Detecting capabilities requires a “capability” entry point, say introduced in version 15. Then in version 22, we introduce something that requires a specific capability, instead of just using capabilities as some kind of optimization. In order to check the now-mandatory capability, we would need version 15 of the ABI, to be able to call the “capability” entry point. So the oldest compatible version is 15, so that we can call the “capabilities” entry point. But starting with version 22, we could still refuse to use a plugin if it does not have the capability we need, even a version 22 plugin.

To summarize, the purpose of the compatibility check is to guarantee well-defined behavior on the entry points we call. It is not to guarantee that a plugin will work, it may still be ruled out for a variety of other reasons.


Thanks
Christophe

> Christophe