linux-kernel - Re: [PATCH][RFC] vsprintf: unify the format decoding layer for its 3 users

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: <20090226233950.0cfcf883.akpm@linux-foundation.org>
Date:	Thu, 26 Feb 2009 23:39:50 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH][RFC] vsprintf: unify the format decoding layer for its
 3 users

On Fri, 27 Feb 2009 08:12:13 +0100 Frederic Weisbecker <fweisbec@...il.com> wrote:

> > Why does the current ftrace_bprintk() need to hack around in (or
> > duplicate) vprintk() internals?  It's a bit grubby, but by placing an
> > upper bound on the number of args, it could simply call vscnprintf()
> > directly?
> >
> 
> The problem is more in the way to save the parameters.
> 
> You have two functions:
> 
> _int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args)
> 
> 
> This one creates a compact binary packet of all args described in the format.
> The result is a binary set of random values on bin_buf.
> 
> 
> _int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf)
> 
> 
> This one lately parses the buffer filled by vbin_printf() and eventually format
> this binary contiguous set of binary values according to the format in fmt (which is the
> same that was passed to vbin_printf()
> The result is formatted in buf.
> 
> vbin uses too much specific write-to-bin_buf operations to allow us to wrap
> vsnprintf()

I don't know what vbin is.

On little-endian architecture you could do something like

	u32 *p = bin_buf;
	char *fmt;
	u32 a0, a1, a2, a3, a4;

#ifdef CONFIG_32BIT
	fmt = (char *)(*bin_buf++);
#else
	<exercise for the reader>
#endif

	a0 = *bin_buf++;
	a1 = *bin_buf++;
	a2 = *bin_buf++;
	a3 = *bin_buf++;
	a4 = *bin_buf++;

	snprintf(somewhere, some_size, fmt, a0, a1, a2, a3, a4, a5);

(as I said, ugly).

but that won't work for 64-bit values on big-endian architectures.  And
it's hacky (and might not even work) for 64-bit on little endian.

Perhaps this is the secret problem which you haven't described yet?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/