Bug #502

UST compatibility issue: 2.1 probe provider with 2.0 liblttng-ust may access beyond structure allocation size

Added by Mathieu Desnoyers over 7 years ago. Updated over 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


I just noticed something quite unpleasant: if we link a probe provider built against lttng-ust 2.1 with a liblttng-ust 2.0, the application may access beyond structure allocation size when traced.

Here is a bit of background explaining this:

1) we want to ensure drop-in compatibility for old applications with newer liblttng-ust versions. Therefore, for 2.0 and 2.1, we chose to leave the soname version at 0.0.0, which means an application (and probe provider) compiled against lttng-ust 2.0 can link to lttng-ust 2.1 without being recompiled.
2) we made sure, in the ABI, to only extend the data structures used within the probe providers. We never shrink them, never remove nor change any of their fields. This means that a 2.0 probe provider can run with a 2.1 liblttng-ust flawlessly: it will just use the fields it knows about.
3) what we failed to consider though was this use-case: if a probe provider is built against lttng-ust 2.1, and linked against an old liblttng-ust 2.0, the probe provider may access 2.1 fields that were not present in 2.0. Since liblttng-ust allocates the memory that contains those structures, this is an out-of-bound access.

So I guess for 2.0 and 2.1, there is not much we can do other than document the limitation (anyone has a better idea ?).

Now the real question is: what should we do to handle this kind of change in the future ?

One possibility would be to ensure the probe provider advertize the lttng-ust version it has been built against, adding a new lttng_probe_register_version() for this. However, this would require to break compatibility between 2.1 and 2.2, which I very much want to avoid.

Another possibility would be to use padding fields in struct lttng_probe_desc to advertize the version. 2.0 and 2.1 would advertize as 0.0 (major.minor probe provider ABI version). The compatibility mapping would be based on the minor version: a new lttng-ust is compatible with older probes, but older lttng-ust are incompatible with newer probes (and therefore their registration is refused). If we ever need to completely break compatibility, the major would be bumped.

Thoughts ?




Updated by Mathieu Desnoyers over 7 years ago

Another possible approach would to add padding to lttng_channel, lttng_event and lttng_session structures (they currently don't have padding, which is part of why we have trouble extending them).


Updated by Anonymous over 7 years ago

Requiring the "tracer version" to be >= the "probe version" doesn't seem unreasonable to me, especially if it saves a bunch of headaches.

I haven't kept in touch with the internals of UST, but advertizing the version in lttng_probe_desc seems like a good idea (centralized, and it gets checked per probe, so some probes can pass while incompatible ones would be refused).

my 2c


Updated by Mathieu Desnoyers over 7 years ago

  • Target version set to 2.2

Updated by Mathieu Desnoyers over 7 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF