linux-kernel - Re: [PATCH] ttyprintk: Add TTY hangup callback.

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]

Date:   Tue, 27 Apr 2021 13:31:30 +0200
From:   Samo Pogačnik <samo_pogacnik@....net>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Jiri Slaby <jirislaby@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Ogness <john.ogness@...utronix.de>,
        linux-kernel@...r.kernel.org,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: [PATCH] ttyprintk: Add TTY hangup callback.

Dne 27.04.2021 (tor) ob 12:08 +0200 je Petr Mladek napisal(a):
> 
> I guess that you mean TPK_PREFIX + "[U] ".
yes

> 
> But you could do this already in tpk_write(). I mean that you could
> parse the given buffer, copy each line to a temporary buffer,
> and call printk(TPK_PREFIX "[U] %s\n", tmp_buf).
> 
> Why is it postponed to tpk_close()?
> 
> IMHO, the printk() in tpk_write() might simplify the logic a bit.
The string received in tpk_write() has no guaranties, that it represents a
complete output line. It has to be treated as a sub-string of a potentially
multi-line massage produced by the userspace code/process. 

The tpk_close() only produces additional output (flush), if the last tpk_write()
string does not end with some end-of-line indication.

> 
> 
> > > 
> > > If you call printk() directly, the caller_id would be from the process
> > > that really wrote the data/message.
> > 
> > It can be a kernel-code originating message printk-ed on behalf of a user
> > task
> > or a kernel-code originating message on behalf of a kernel task. Or it may
> > be a
> > user-code originating message on behalf of its task, when printk-ed via
> > ttyprintk.
> 
> Exactly. Now, I am not sure if you think that this good or bad.
> 
> IMHO, it is much better to use caller_id of the process/context that
> wrote the data/message instead of the process that caused the final
> tpk_close().
> 
IMHO, it is good that output provides info about all the above cases and
especially that particular output is not produced by the kernel code itself.

best regards, samo