linux-kernel - [PATCH 0/2] printk: Support message continuation from /dev/kmsg

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

Message-ID: <0102016e84a36465-3c9627a0-8511-4bfb-9f49-9cc62fe1f692-000000@eu-west-1.amazonses.com>
Date:   Tue, 19 Nov 2019 17:08:50 +0000
From:   James Byrne <james.byrne@...gamienergy.com>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     James Byrne <james.byrne@...gamienergy.com>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: [PATCH 0/2] printk: Support message continuation from /dev/kmsg

Hello,

I am submitting two patches to printk which possibly need a little
context to explain why we found them to be necessary.

We develop an embedded Linux device in which we use a unified logging
scheme where the userspace applications write their logs into /dev/kmsg,
and then log reader applications (like dmesg) read them out for logging
to the console and syslog. There are some advantages to this scheme,
such as having common timestamps for kernel and userspace messages and
being more easily able to correlate how userspace application events
trigger kernel activity.

We recently upgraded our kernel from 3.18 to 4.14 and found that
behaviour around continuation lines we had been using no longer worked.
Since it is not possible to write more than LOG_LINE_MAX (992) bytes
into /dev/kmsg in one write, we were relying on the fact that we could
break up a longer message into several consecutive writes where only the
last write of the sequence was terminated by a newline, and the kernel
would treat the messages as a sequence of continuations. When you then
read the messages back from /dev/kmsg you could tell this because the
first record of the sequence would be flagged with 'c' and subsequent
ones with '+', meaning that the log reader could easily join them back
together. Obviously there are times where a sequence could be broken by
an unrelated printk occuring in the middle, but it generally worked very
well.

Subsequent kernel changes mean that it is currently not possible to
write continuation lines into the printk buffer from userspace, and also
that the flags that you read back in /dev/kmsg records are now either
'-' or 'c', something I previously submitted a documentation patch for
in commit 085a3a8fdf3e ("ABI: Update dev-kmsg documentation to match
current kernel behaviour"), which makes the documentation correct, but
glosses over the fact that the flags are no longer useful.

These patches are what we have done to resolve this issue, by giving a
new way to write continuation lines into /dev/kmsg from userspace, and
the have meaningful flags come back that will allow a reader to join the
lines together again.

James Byrne

James Byrne (2):
  printk: Make continuation flags from /dev/kmsg useful again
  printk: Support message continuation from /dev/kmsg

 Documentation/ABI/testing/dev-kmsg | 20 +++++++++++++-------
 kernel/printk/printk.c             | 25 +++++++++++++++++++++++--
 2 files changed, 36 insertions(+), 9 deletions(-)

-- 
2.24.0