linux-kernel - Re: [PATCH 0/2] introduce DUMP_PREFIX

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: <YAf1lS8zsHwhShCr@alley>
Date:   Wed, 20 Jan 2021 10:19:17 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Timur Tabi <timur@...nel.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Matthew Wilcox <willy@...radead.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        roman.fietze@...na.com, Steven Rostedt <rostedt@...dmis.org>,
        John Ogness <john.ogness@...utronix.de>, linux-mm@...ck.org,
        Akinobu Mita <akinobu.mita@...il.com>
Subject: Re: [PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps

On Tue 2021-01-19 13:55:29, Timur Tabi wrote:
> On 1/19/21 1:45 PM, Kees Cook wrote:
> > How about this so the base address is hashed once, with the offset added
> > to it for each line instead of each line having a "new" hash that makes
> > no sense:
> > 
> > diff --git a/lib/hexdump.c b/lib/hexdump.c
> > index 9301578f98e8..20264828752d 100644
> > --- a/lib/hexdump.c
> > +++ b/lib/hexdump.c
> > @@ -242,12 +242,17 @@ void print_hex_dump(const char *level, const char *prefix_str, int prefix_type,
> >   		    const void *buf, size_t len, bool ascii)
> >   {
> >   	const u8 *ptr = buf;
> > +	const u8 *addr;
> >   	int i, linelen, remaining = len;
> >   	unsigned char linebuf[32 * 3 + 2 + 32 + 1];
> >   	if (rowsize != 16 && rowsize != 32)
> >   		rowsize = 16;
> > +	if (prefix_type == DUMP_PREFIX_ADDRESS &&
> > +	    ptr_to_hashval(ptr, &addr))
> > +		addr = 0;
> > +
> >   	for (i = 0; i < len; i += rowsize) {
> >   		linelen = min(remaining, rowsize);
> >   		remaining -= rowsize;
> > @@ -258,7 +263,7 @@ void print_hex_dump(const char *level, const char *prefix_str, int prefix_type,
> >   		switch (prefix_type) {
> >   		case DUMP_PREFIX_ADDRESS:
> >   			printk("%s%s%p: %s\n",
> > -			       level, prefix_str, ptr + i, linebuf);
> > +			       level, prefix_str, addr + i, linebuf);
> 
> Well, this is better than nothing, but not by much.  Again, as long as %px
> exists for printk(), I just cannot understand any resistance to allowing it
> in print_hex_dump().
> 
> Frankly, I think this patch and my patch should both be added.  During
> debugging, it's very difficult if not impossible to work with hashed
> addresses.  I use print_hex_dump() with an unhashed address all the time,
> either by applying my patch to my own kernel or just replacing the %p with
> %px.

This was my view as well. People should not need to add features into
hexdump code when they want to use is for debugging. And the address
is pretty useful.

A solution might be to prevent using this in the mainline:

   + it might be reported by checkpatch.pl

   + it might print some bold warning on the first use, similar to
     trace_printk().

Or we need this in the mainline. Then the use of %pK looks
like the best compromise to me. We could also add some warning
as a comment and use some provocative name for the flag
as suggested by Matthew.

And we should definitely add Linus into CC when sending v2.
His expected opinion has been mentioned several times in this
thread. It would be better to avoid these speculations
and get his real opinion. IMHO, it is too late to add
him in this long thread.

Best Regards,
Petr