linux-kernel - [for-linus][PATCH 0/3] tracing: Fixes for v6.8

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-next>] [day] [month] [year] [list]

Message-ID: <20240306184244.754263547@goodmis.org>
Date: Wed, 06 Mar 2024 13:42:44 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: linux-kernel@...r.kernel.org
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Subject: [for-linus][PATCH 0/3] tracing: Fixes for v6.8

Tracing fixes for v6.8-rc7:

- The size of a string written into trace_marker was determined by
  the size of the sub-buffer in the ring buffer. That size is
  dependent on the PAGE_SIZE of the architecture as it can be mapped
  into user space. But on PowerPC, where PAGE_SIZE is 64K, that made
  the limit of the string of writing into trace_marker 64K.

  One of the selftests looks at the size of the ring buffer sub-buffers
  and writes that plus more into the trace_marker. The write will take
  what it can and report back what it consumed so that the user space
  application (like echo) will write the rest of the string. The string
  is stored in the ring buffer and can be read via the "trace" or
  "trace_pipe" files.

  The reading of the ring buffer uses vsnprintf(), which uses a precision
  "%.*s" to make sure it only reads what is stored in the buffer, as
  a bug could cause the string to be non terminated.

  With the combination of the precision change and the PAGE_SIZE of 64K
  allowing huge strings to be added into the ring buffer, plus the test
  that would actually stress that limit, a bug was reported that
  the precision used was too big for "%.*s" as the string was close to
  64K in size and the max precision of vsnprintf is 32K.

  Linus suggested not to have that precision as it could hide a bug
  if the string was again stored without a nul byte.

  Another issue that was brought up is that the trace_seq buffer is
  also based on PAGE_SIZE even though it is not tied to the architecture
  limit like the ring buffer sub-buffer is. Having it be 64K * 2 is
  simply just too big and wasting memory on systems with 64K page sizes.
  It is now hardcoded to 8K which is what all other architectures with
  4K PAGE_SIZE has.

  Finally, the write to trace_marker is now limited to 4K as there is no
  reason to write larger strings into trace_marker.

Steven Rostedt (Google) (3):
      tracing: Remove precision vsnprintf() check from print event
      tracing: Limit trace_seq size to just 8K and not depend on architecture PAGE_SIZE
      tracing: Limit trace_marker writes to just 4K

----
 include/linux/trace_seq.h   |  8 +++++++-
 kernel/trace/trace.c        | 10 +++++-----
 kernel/trace/trace_output.c |  6 ++----
 3 files changed, 14 insertions(+), 10 deletions(-)