linux-kernel - Re: [PATCH] kernel/printk: add kmsg SEEK

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: <20200317020326.GC219881@google.com>
Date:   Tue, 17 Mar 2020 11:03:26 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Bruno Meneguele <bmeneg@...hat.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        pmladek@...e.com, sergey.senozhatsky@...il.com, rostedt@...dmis.org
Subject: Re: [PATCH] kernel/printk: add kmsg SEEK_CUR handling

On (20/03/13 08:02), Bruno Meneguele wrote:
> Ok, I poorly expressed the notion of "documentantion". The userspace
> doesn't tell about returning -ESPIPE, but to the functions work properly
> they watch for -ESPIPE returning from the syscall. For instance, gblic
> dprintf() implementation:
> 
> dprintf:
>   __vdprintf_internal:
>     _IO_new_file_attach:
> 
>   if (_IO_SEEKOFF (fp, (off64_t)0, _IO_seek_cur, _IOS_INPUT|_IOS_OUTPUT)
>       == _IO_pos_BAD && errno != ESPIPE)
>     return NULL;
> 
> With that, if the seek fails, but return anything other than ESPIPE the
> dprintf() will also fail returning -EINVAL to dprintf() caller. While if
> ESPIPE is returned, it's "ignored" and the call still works. The way we
> have today make kmsg an exception case among the rest of the system
> files where you can open with dprintf.
> 
> One of the things I could agree with is removing the SEEK call from
> dprintf, since fprintf basically follows the same steps, but doesn't
> seek anything.  But at the same time, IMO it makes sense to make kmsg
> interface complaint with the errno return values.

The code in questions is very old. So let's add the missing bit to the
kernel. At the same time, we probably can have a slightly more detailed
documentation / code comment.

	-ss