linux-kernel - Re: [RELEASE] LTTng-modules 2.11.9 and 2.12.6 (Linux kernel tracer)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1811223777.46126.1621023403092.JavaMail.zimbra@efficios.com>
Date:   Fri, 14 May 2021 16:16:43 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     lttng-dev <lttng-dev@...ts.lttng.org>,
        Diamon discuss <diamon-discuss@...ts.linuxfoundation.org>,
        linux-trace-users <linux-trace-users@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Cc:     Genevieve Bastien <gbastien+lttng@...satic.net>
Subject: Re: [RELEASE] LTTng-modules 2.11.9 and 2.12.6 (Linux kernel tracer)

----- On May 14, 2021, at 3:52 PM, Mathieu Desnoyers mathieu.desnoyers@...icios.com wrote:

> Hi,
> 
> The 2.11.9 and 2.12.6 releases of the LTTng kernel tracer are the latest bug fix
> releases
> of the 2.11 and 2.12 stable branches of the LTTng modules project.
> 
> There are a few minor bug fixes, but those are the noteworthy changes:
> 
> - Support for 5.12 Linux kernels,
> - Support recent stable kernel branches 4.14, 4.19, 5.4,
> - Support for newer Ubuntu 4.15, 5.4 and RHEL 8.2/8.3 kernels,
> - Fix: increment buffer offset when failing to copy from user-space:
> 
>    Upon failure to copy from user-space due to failing access ok check, the
>    ring buffer offset is not incremented, which could generate unreadable
>    traces because we don't account for the padding we write into the ring
>    buffer.
>    
>    Note that this typically won't affect a common use-case of copying
>    strings from user-space, because unless mprotect is invoked within a
>    narrow race window (between user strlen and user strcpy), the strlen
>    will fail on access ok when calculating the space to reserve, which will
>    match what happens on strcpy.

There is one additional noteworthy set of changes in lttng-modules 2.12.6:

        * Disable block rwbs bitwise enum in default build
        * Disable sched_switch bitwise enum in default build
        * Add experimental bitwise enum config option

The block rwbs bitwise enum and sched switch bitwise enum were introduced late
in the 2.12 rc cycle, and ended up producing traces which were not strictly
conformant with the CTF 1.8 specifications: they were producing enumerations
with values associated with no known labels.

This causes Babeltrace 1 and 2, with default options, to generate warnings when
viewing kernel traces.

So those commits introduce a new build-time option which can optionally enable
those bitwise enumerations, e.g.:

 make CONFIG_LTTNG_EXPERIMENTAL_BITWISE_ENUM=y

So until we finalize the CTF2 specification and its implementation in the tracers
and trace viewers, this provides a way for experimental users of LTTng-modules to
keep generating those bitwise enumerations without producing warnings in the
default use-case.

Without this option, a simple integer field is emitted in the trace rather than a
bitwise enumeration.

Thanks,

Mathieu


> 
> Thanks,
> 
> Mathieu
> 
> Project website: https://lttng.org
> Documentation: https://lttng.org/docs
> Download link: https://lttng.org/download
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

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