[lttng-dev] [RELEASE] LTTng-UST 2.13.2 and 2.12.4 (Linux user-space tracer)

[Mathieu Desnoyers]

Hi,

This is a stable release announcement for the LTTng-UST project. LTTng-UST
is a tracer for Linux user-space applications. The respective versions are
2.13.2 and 2.12.4.

The most important change introduced in these releases is the implementation
of a LTTng-UST Log4j 2.x log appender. Note that in the context of
CVE-2021-45046 [2], LTTng-UST per-se is not affected because it does not
use Log4j for its own logging, but rather implements a log appender (a log
"sink").

Here are the noteworthy changes:

In both 2.13.2 and 2.12.4:

* Add a Log4j 2.x Java agent

    Before those releases, LTTng-UST only implemented a Log4j 1.x appender.
    Considering that Log4j 1.x has been unmaintained since 2015 [1], and that
    a range of Log4j 2.x versions are affected by the critical vulnerability
    CVE-2021-45046, allowing Log4j users which use LTTng-UST as a log appender
    to upgrade from Log4j 1.x to an up-to-date 2.x is very much relevant,
    thus explaining why this new feature is introduced in LTTng-UST stable
    releases.

    This adds a new agent to the LTTng-UST Java agents suite supporting the
    Log4j 2.x logging backend.

    This backport differs from the master branch for the
    '--enable-java-agent-all' option won't select this new agent since we
    wanted to avoid introducing a new dependency in existing configurations.

    The name of the new agent jar file is "lttng-ust-agent-log4j2.jar".
    It will be installed in the arch-agnostic "$prefix/share/java" path
    e.g: "/usr/share/java".
    
    It uses the same jni library "liblttng-ust-log4j-jni.so" as the Log4j 1.x agent.
    
    The agent was designed as a mostly drop-in replacement for applications
    upgrading from Log4j 1.x to 2.x. It requires no modification to the
    tracing configuration as it uses the same domain "-l / LOG4J" and the
    loglevels integer representations are converted to the Log4j 1.x values
    (excluding custom loglevels).

* Fix: concurrent exec(2) file descriptor leak

    If exec(2) is executed by the application concurrently with LTTng-UST
    listener threads between the creation of a file descriptor with
    socket(2), recvmsg(2), or pipe(2) and call to fcntl(3) FD_CLOEXEC, those
    file descriptors will stay open after the exec, which is not intended.
    
    As a consequence, shared memory files for ring buffers can stay present
    on the file system for long-running traced processes.

    Rather than fcntl(2) FD_CLOEXEC to make sure the file descriptors are
    closed on exec immediately upon their creation.

Noteworthy specifically in 2.13.2:

* Fix: sample discarded events count before reserve

    Sampling the discarded events count in the buffer_end callback is done
    out of order, and may therefore include increments performed by following
    events (in following packets) if the thread doing the end-of-packet
    event write is preempted for a long time.
    
    Sampling the event discarded counts before reserving space for the last
    event in a packet, and keeping this as part of the private ring buffer
    context, should fix this race.

    This fix is only part of the 2.13 stable branch and not backported to
    2.12 because the lib ring buffer code used to implement this fix did not
    exist in 2.12. Given that the impact of this bug is only imprecision of
    discarded event reporting in corner-case scenarios (small impact, rare
    occurrence), the complexity of implementing this fix in 2.12 is not justified.
    The effect of this issue is that the lttng-tools
    tests/regression/tools/streaming/test_high_throughput_limits test is flaky.

Feedback is welcome!

Thanks,

Mathieu

[1] https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
[2] https://www.cve.org/CVERecord?id=CVE-2021-45046

Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com