linux-kernel - Re: -Wfortify-source in kernel/printk/printk.c

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]

Message-ID: <20200130065730.GG115889@google.com>
Date:   Thu, 30 Jan 2020 15:57:30 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org, clang-built-linux@...glegroups.com
Subject: Re: -Wfortify-source in kernel/printk/printk.c

On (20/01/29 22:39), Joe Perches wrote:
> > > It isn't wrong, given that when CONFIG_PRINTK is disabled, text's length
> > > is 0 (LOG_LINE_MAX and PREFIX_MAX are both zero). How should this
> > > warning be dealt this? I am not familiar enough with the printk code to
> > > say myself.
> > 
> > It's not wrong.
> > 
> > Unless I'm missing something completely obvious: with disabled printk()
> > we don't have any functions that can append messages to the logbuf, hence
> > we can't overflow it. So the error in question should never trigger.
> > 
> > - Normal printk() is void, so kernel cannot append messages;
> > - dev_printk() is void, so drivers cannot append messages and dicts;
> > - devkmsg_write() is void, so user space cannot write to logbuf.
> > 
> > So I think we should never trigger that overflow (assuming that I
> > didn't miss something) message.
> > 
> > In any case feel free to submit a patch - switch it to snprintf().
> 
> and/or make the code depend on CONFIG_PRINTK

console_unlock() still needs to at least up() the console semaphore.
We don't have printk(), but the tty subsystem is still there and serial
consoles and definitely still up and running. So... maybe we can have
two versions of console_unlock().

	-ss