linux-kernel - Re: [PATCH printk v3 5/6] printk: introduce console_get_next_message() and console

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

Message-ID: <871qoafve1.fsf@jogness.linutronix.de>
Date:   Wed, 04 Jan 2023 11:32:30 +0106
From:   John Ogness <john.ogness@...utronix.de>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk v3 5/6] printk: introduce
 console_get_next_message() and console_message

On 2023-01-03, Petr Mladek <pmladek@...e.com> wrote:
>> The current atomic console proposal allocates 1x cbuf per-cpu and 4x
>> meta-data per-cpu. Different contexts of a cpu will have different
>> meta-data, but all the contexts of a cpu will share the same cbuf.
>>
>> If cbufs become embedded in cmsg, then we would allocate 1x cmsg
>> per-cpu. But the atomic consoles would still need their own 4x per-cpu
>> meta-data.
>
> Do we really need 4x the meta data?

Having per-context meta-data helps minimize data clobbering. For
example, the message-formatting functions would not need to worry about
@cmsg->len changing underneath them. This can be solved with a
READ_ONCE() to a local variable and the function only using the local
copy, but it will mean more copying of variables.

> The metadata describe the state of the buffer. Using the buffer in one
> context invalidates the metadata in the other context.

Yes, but the message-formatting functions are the ones preparing that
meta-data. They must then be able to handle an interrupting context
changing that meta-data.

>> For v4 I will drop the console_buffers struct. I will use your
>> suggestion.
>
> Please, do not do it just to make me happy. My intention
> is to keep things simple. And keeping the two structures
> synced needs an extra code.
>
> If you are sure that the separation will really be needed
> in the future then feel free to keep the two structures.

Currently the message-formatting functions do not care about clobbering
of the text buffers. They blindly just move things around using the
meta-data as safety boundaries. This can lead to a formatted-buffer that
contains garbage, but an interrupted context will not print that buffer
in the end. The important thing is that the garbage was created safely.

Avoiding a separate console_buffers structure may simplify the
structures, but it requires robustifying the message-formatting
functions to be tolerant for meta-data clobbering.

I am currently implementing such changes to see if it is feasible.

John