Re: [PATCH] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses
On Fri, Jan 15, 2021 at 3:24 AM Petr Mladek wrote: > By other words, every print_hex_dump() used need to be reviewed in > which context might be called. I did a rough analysis of all current usage of DUMP_PREFIX_ADDRESS in the kernel, compared to the introduction of %px and hashed addresses, using git-blame to find the most recent commit that modifies a line that contains _ADDRESS. Of 150 cases, 110 of them are newer than %px, so I'm assuming that these developers chose _ADDRESS instead of _OFFSET knowing that the addresses are hashed. > > If you want, I can include a patch that changes a few callers of > > print_hex_dump() to use DUMP_PREFIX_UNHASHED, based on what I think would be > > useful. > > It would be nice. I have a v2 that I'm about to post, and I included a patch that modifies check_poison_mem() in mm/page_poison.c. I chose this file because I figured actual addresses would probably be necessary for tracking memory-related errors. Also, that call to print_hex_dump() was added back in 2009, so it predates the introduction of %px.
Re: [PATCH] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses
On Thu 2021-01-14 20:56:36, Timur Tabi wrote: > On 1/11/21 7:30 PM, Andrew Morton wrote: > > I doubt if Kees (or I or anyone else) can review this change because > > there are no callers which actually use the new DUMP_PREFIX_UNHASHED. > > Is it intended that some other places in the kernel be changed to use > > this? If so, please describe where and why, so that others can better > > understand both the requirement and the security implications. > > In my opinion, hashed addresses make no sense in a hexdump, so I would say > that ALL callers should change. But none of the drivers I've written call > print_hex_dump(), so I can't make those changes myself. I know that you probably know it because you introduced new mode instead of updating the existing one. But to be sure. We need to be careful here. The hashed pointer has been introduced for a reason. It prevents leaking pointers and helping bad guys. The original plan was to introduce %pK. It was supposed to prevent non-privileged users from seeing the real pointer value. It did not really worked because it was only rarely used. The plain %p was heavily used in historical and even in a new code. By other words, every print_hex_dump() used need to be reviewed in which context might be called. > > If it is intended that this be used mainly for developer debug and not > > to be shipped in the mainline kernel then let's get this info into the > > changelog as well. > > I definitely want this patch included in the mainline kernel. Just because > there aren't any users today doesn't mean that there won't be. In fact, I > suspect that most current users haven't noticed that the addresses have > changed or don't care any more, but if they were to write the code today, > they would use unhashed addresses. I am pretty sure that will look for this functionality sooner or later. The hashed pointers make debugging really complicated. > If you want, I can include a patch that changes a few callers of > print_hex_dump() to use DUMP_PREFIX_UNHASHED, based on what I think would be > useful. It would be nice. Best Regards, Petr
Re: [PATCH] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses
On 1/11/21 7:30 PM, Andrew Morton wrote: I doubt if Kees (or I or anyone else) can review this change because there are no callers which actually use the new DUMP_PREFIX_UNHASHED. Is it intended that some other places in the kernel be changed to use this? If so, please describe where and why, so that others can better understand both the requirement and the security implications. In my opinion, hashed addresses make no sense in a hexdump, so I would say that ALL callers should change. But none of the drivers I've written call print_hex_dump(), so I can't make those changes myself. If it is intended that this be used mainly for developer debug and not to be shipped in the mainline kernel then let's get this info into the changelog as well. I definitely want this patch included in the mainline kernel. Just because there aren't any users today doesn't mean that there won't be. In fact, I suspect that most current users haven't noticed that the addresses have changed or don't care any more, but if they were to write the code today, they would use unhashed addresses. If you want, I can include a patch that changes a few callers of print_hex_dump() to use DUMP_PREFIX_UNHASHED, based on what I think would be useful.
Re: [PATCH] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses
On Mon, 11 Jan 2021 11:10:56 +0100 Petr Mladek wrote: > Adding Kees into CC because it is security related. > Adding Andrew into CC because he usually takes patches for hexdump. > > On Wed 2021-01-06 15:35:47, Timur Tabi wrote: > > Hashed addresses are useless in hexdumps unless you're comparing > > with other hashed addresses, which is unlikely. However, there's > > no need to break existing code, so introduce a new prefix type > > that prints unhashed addresses. > > > > Signed-off-by: Timur Tabi > > Cc: Roman Fietze > > I agree that there should be way to print the real address. > > And it is sane to add a new mode so that the current > users stay hashed. > I doubt if Kees (or I or anyone else) can review this change because there are no callers which actually use the new DUMP_PREFIX_UNHASHED. Is it intended that some other places in the kernel be changed to use this? If so, please describe where and why, so that others can better understand both the requirement and the security implications. If it is intended that this be used mainly for developer debug and not to be shipped in the mainline kernel then let's get this info into the changelog as well.
Re: [PATCH] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses
Adding Kees into CC because it is security related.
Adding Andrew into CC because he usually takes patches for hexdump.
On Wed 2021-01-06 15:35:47, Timur Tabi wrote:
> Hashed addresses are useless in hexdumps unless you're comparing
> with other hashed addresses, which is unlikely. However, there's
> no need to break existing code, so introduce a new prefix type
> that prints unhashed addresses.
>
> Signed-off-by: Timur Tabi
> Cc: Roman Fietze
I agree that there should be way to print the real address.
And it is sane to add a new mode so that the current
users stay hashed.
Reviewed-by: Petr Mladek
> ---
> include/linux/printk.h | 3 ++-
> lib/hexdump.c | 9 +++--
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/printk.h b/include/linux/printk.h
> index fe7eb2351610..5d833bad785c 100644
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -567,7 +567,8 @@ extern const struct file_operations kmsg_fops;
> enum {
> DUMP_PREFIX_NONE,
> DUMP_PREFIX_ADDRESS,
> - DUMP_PREFIX_OFFSET
> + DUMP_PREFIX_OFFSET,
> + DUMP_PREFIX_UNHASHED,
> };
> extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
> int groupsize, char *linebuf, size_t linebuflen,
> diff --git a/lib/hexdump.c b/lib/hexdump.c
> index 9301578f98e8..b5acfc4168a8 100644
> --- a/lib/hexdump.c
> +++ b/lib/hexdump.c
> @@ -211,8 +211,9 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
> * @level: kernel log level (e.g. KERN_DEBUG)
> * @prefix_str: string to prefix each line with;
> * caller supplies trailing spaces for alignment if desired
> - * @prefix_type: controls whether prefix of an offset, address, or none
> - * is printed (%DUMP_PREFIX_OFFSET, %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_NONE)
> + * @prefix_type: controls whether prefix of an offset, hashed address,
> + * unhashed address, or none is printed (%DUMP_PREFIX_OFFSET,
> + * %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_UNHASHED, %DUMP_PREFIX_NONE)
> * @rowsize: number of bytes to print per line; must be 16 or 32
> * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
> * @buf: data blob to dump
> @@ -256,6 +257,10 @@ void print_hex_dump(const char *level, const char
> *prefix_str, int prefix_type,
> linebuf, sizeof(linebuf), ascii);
>
> switch (prefix_type) {
> + case DUMP_PREFIX_UNHASHED:
> + printk("%s%s%px: %s\n",
> +level, prefix_str, ptr + i, linebuf);
> + break;
> case DUMP_PREFIX_ADDRESS:
> printk("%s%s%p: %s\n",
> level, prefix_str, ptr + i, linebuf);
> --
> 2.25.1
Re: [PATCH] lib/hexdump
On Thu, 3 May 2007 09:01:31 +0200 (MEST) Jan Engelhardt wrote: > > On May 2 2007 15:35, Randy Dunlap wrote: > > > >Add hex_dumper() to lib/hexdump.c and linux/kernel.h. > > Right - we've got the second user already, namely the PANIC/OOPS > code print. (The last line, aka "bytes at EIP" under Windows.) > > Jan 6 14:40:14 deekin kernel: Call Trace: > Jan 6 14:40:14 deekin kernel: [] is_complete+0x2c3/0x310 > Jan 6 14:40:14 deekin kernel: [] run+0x30/0x40 > Jan 6 14:40:14 deekin kernel: [] worker_thread+0x1bd/0x2b0 > Jan 6 14:40:14 deekin kernel: [] run+0x0/0x40 > Jan 6 14:40:14 deekin kernel: [] default_wake_function+0x0/0x20 > Jan 6 14:40:14 deekin kernel: [] ret_from_fork+0x6/0x20 > Jan 6 14:40:14 deekin kernel: [] default_wake_function+0x0/0x20 > Jan 6 14:40:14 deekin kernel: [] worker_thread+0x0/0x2b0 > Jan 6 14:40:14 deekin kernel: [] kernel_thread_helper+0x5/0x10 > Jan 6 14:40:14 deekin kernel: Code: 89 02 8b 41 04 8b 40 3c 8b 53 04 89 42 3c > 8b 41 04 plus intel wireless drivers, 2 MTD/flash drivers, and search kernel tree for hexdump (function name that I wanted to use, but it's already used), hex_dump, dump_hex, dump_mem, etc. Andrew says that he knew of 9 hex dumpers in-tree. :) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** (sorry about email address change; other address not working for some reason) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
On May 2 2007 15:35, Randy Dunlap wrote: > >Add hex_dumper() to lib/hexdump.c and linux/kernel.h. Right - we've got the second user already, namely the PANIC/OOPS code print. (The last line, aka "bytes at EIP" under Windows.) Jan 6 14:40:14 deekin kernel: Call Trace: Jan 6 14:40:14 deekin kernel: [] is_complete+0x2c3/0x310 Jan 6 14:40:14 deekin kernel: [] run+0x30/0x40 Jan 6 14:40:14 deekin kernel: [] worker_thread+0x1bd/0x2b0 Jan 6 14:40:14 deekin kernel: [] run+0x0/0x40 Jan 6 14:40:14 deekin kernel: [] default_wake_function+0x0/0x20 Jan 6 14:40:14 deekin kernel: [] ret_from_fork+0x6/0x20 Jan 6 14:40:14 deekin kernel: [] default_wake_function+0x0/0x20 Jan 6 14:40:14 deekin kernel: [] worker_thread+0x0/0x2b0 Jan 6 14:40:14 deekin kernel: [] kernel_thread_helper+0x5/0x10 Jan 6 14:40:14 deekin kernel: Code: 89 02 8b 41 04 8b 40 3c 8b 53 04 89 42 3c 8b 41 04 Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
On May 2 2007 15:35, Randy Dunlap wrote: Add hex_dumper() to lib/hexdump.c and linux/kernel.h. Right - we've got the second user already, namely the PANIC/OOPS code print. (The last line, aka bytes at EIP under Windows.) Jan 6 14:40:14 deekin kernel: Call Trace: Jan 6 14:40:14 deekin kernel: [c02060b3] is_complete+0x2c3/0x310 Jan 6 14:40:14 deekin kernel: [c02037c0] run+0x30/0x40 Jan 6 14:40:14 deekin kernel: [c0125b6d] worker_thread+0x1bd/0x2b0 Jan 6 14:40:14 deekin kernel: [c0203790] run+0x0/0x40 Jan 6 14:40:14 deekin kernel: [c0113b10] default_wake_function+0x0/0x20 Jan 6 14:40:14 deekin kernel: [c0108fd6] ret_from_fork+0x6/0x20 Jan 6 14:40:14 deekin kernel: [c0113b10] default_wake_function+0x0/0x20 Jan 6 14:40:14 deekin kernel: [c01259b0] worker_thread+0x0/0x2b0 Jan 6 14:40:14 deekin kernel: [c0107175] kernel_thread_helper+0x5/0x10 Jan 6 14:40:14 deekin kernel: Code: 89 02 8b 41 04 8b 40 3c 8b 53 04 89 42 3c 8b 41 04 Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
On Thu, 3 May 2007 09:01:31 +0200 (MEST) Jan Engelhardt wrote: On May 2 2007 15:35, Randy Dunlap wrote: Add hex_dumper() to lib/hexdump.c and linux/kernel.h. Right - we've got the second user already, namely the PANIC/OOPS code print. (The last line, aka bytes at EIP under Windows.) Jan 6 14:40:14 deekin kernel: Call Trace: Jan 6 14:40:14 deekin kernel: [c02060b3] is_complete+0x2c3/0x310 Jan 6 14:40:14 deekin kernel: [c02037c0] run+0x30/0x40 Jan 6 14:40:14 deekin kernel: [c0125b6d] worker_thread+0x1bd/0x2b0 Jan 6 14:40:14 deekin kernel: [c0203790] run+0x0/0x40 Jan 6 14:40:14 deekin kernel: [c0113b10] default_wake_function+0x0/0x20 Jan 6 14:40:14 deekin kernel: [c0108fd6] ret_from_fork+0x6/0x20 Jan 6 14:40:14 deekin kernel: [c0113b10] default_wake_function+0x0/0x20 Jan 6 14:40:14 deekin kernel: [c01259b0] worker_thread+0x0/0x2b0 Jan 6 14:40:14 deekin kernel: [c0107175] kernel_thread_helper+0x5/0x10 Jan 6 14:40:14 deekin kernel: Code: 89 02 8b 41 04 8b 40 3c 8b 53 04 89 42 3c 8b 41 04 plus intel wireless drivers, 2 MTD/flash drivers, and search kernel tree for hexdump (function name that I wanted to use, but it's already used), hex_dump, dump_hex, dump_mem, etc. Andrew says that he knew of 9 hex dumpers in-tree. :) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** (sorry about email address change; other address not working for some reason) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
On Wed, 2 May 2007 16:06:35 -0700 Andrew Morton wrote: > On Wed, 02 May 2007 15:56:48 -0700 > Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > Andrew Morton wrote: > > > On Wed, 2 May 2007 15:35:56 -0700 > > > Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > > >> From: Randy Dunlap <[EMAIL PROTECTED]> > > >> > > >> Based on ace_dump_mem() from Grant Likely for the Xilinx > > >> SystemACE CompactFlash interface. > > >> > > >> Add hex_dumper() to lib/hexdump.c and linux/kernel.h. > > >> > > >> This patch adds the function 'hex_dumper' which can be used to perform a > > >> hex + ASCII dump of data to syslog, in an easily viewable format, thus > > >> providing a common text hex dump format. > > >> > > >> It does not provide a hexdump_to_buffer() function. > > >> if someone needs that, we'll have to add it. > > >> > > >> Example usage: > > >> hex_dumper(KERN_DEBUG, data, length); > > >> > > > > > > Fair enough. This is the sort of thing one could easily overdesign ;) > > > > The Intel version also returned the number of bytes printed. > > and they had a hexdump_to_buffer() for sysfs output. > > > > Yeah, that's where we get into creature feeping. Really it should be > passed the address of a function which performs the per-char output and > which is passed a bunch of args so it can do its stuff. But doing printk > of a single char at a time is a bit inefficient and produces mangled output > on SMP. And then we don't know the length of the output and we'd like it > dynamically allocated and on and on. > > Ho hum. Perhaps a middle ground is to implement hexdump-to-memory as the > core function. hex_dumper() becomes a simple wrapper around that. (but > how big is its buffer? One line would be OK, I guess) Yeah, I almost did it that way. We'll see. > > OK, that's one way to do it. I'll wait a bit for other comments. > > Good luck ;) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
On Wed, 02 May 2007 15:56:48 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > On Wed, 2 May 2007 15:35:56 -0700 > > Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > >> From: Randy Dunlap <[EMAIL PROTECTED]> > >> > >> Based on ace_dump_mem() from Grant Likely for the Xilinx > >> SystemACE CompactFlash interface. > >> > >> Add hex_dumper() to lib/hexdump.c and linux/kernel.h. > >> > >> This patch adds the function 'hex_dumper' which can be used to perform a > >> hex + ASCII dump of data to syslog, in an easily viewable format, thus > >> providing a common text hex dump format. > >> > >> It does not provide a hexdump_to_buffer() function. > >> if someone needs that, we'll have to add it. > >> > >> Example usage: > >>hex_dumper(KERN_DEBUG, data, length); > >> > > > > Fair enough. This is the sort of thing one could easily overdesign ;) > > The Intel version also returned the number of bytes printed. > and they had a hexdump_to_buffer() for sysfs output. > Yeah, that's where we get into creature feeping. Really it should be passed the address of a function which performs the per-char output and which is passed a bunch of args so it can do its stuff. But doing printk of a single char at a time is a bit inefficient and produces mangled output on SMP. And then we don't know the length of the output and we'd like it dynamically allocated and on and on. Ho hum. Perhaps a middle ground is to implement hexdump-to-memory as the core function. hex_dumper() becomes a simple wrapper around that. (but how big is its buffer? One line would be OK, I guess) > OK, that's one way to do it. I'll wait a bit for other comments. Good luck ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
Andrew Morton wrote: On Wed, 2 May 2007 15:35:56 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: From: Randy Dunlap <[EMAIL PROTECTED]> Based on ace_dump_mem() from Grant Likely for the Xilinx SystemACE CompactFlash interface. Add hex_dumper() to lib/hexdump.c and linux/kernel.h. This patch adds the function 'hex_dumper' which can be used to perform a hex + ASCII dump of data to syslog, in an easily viewable format, thus providing a common text hex dump format. It does not provide a hexdump_to_buffer() function. if someone needs that, we'll have to add it. Example usage: hex_dumper(KERN_DEBUG, data, length); Fair enough. This is the sort of thing one could easily overdesign ;) The Intel version also returned the number of bytes printed. and they had a hexdump_to_buffer() for sysfs output. include/linux/kernel.h |1 lib/Makefile |2 - lib/hexdump.c | 51 + 3 files changed, 53 insertions(+), 1 deletion(-) --- /dev/null +++ linux-2.6.21-git4/lib/hexdump.c @@ -0,0 +1,51 @@ +/** + * hex_dumper - print a text hex dump to syslog for a binary blob of data + * @level: kernel log level (e.g. KERN_DEBUG) + * @buf: data blob to dump + * @len: number of bytes in the @buf + * + * Given a buffer of u8 data, hex_dumper() will print a hex + ASCII dump + * to the kernel log at the specified kernel log level. + * + * E.g.: + * hex_dumper(KERN_DEBUG, frame->data, frame->len); + * + * Prints the offsets of the block of memory, not addresses: + * 0009ab42: 40414243 44454647 48494a4b [EMAIL PROTECTED] HIJKLMNO But I suspect it should be printing the addresses, for many callers. In which case we'd need a separate arg (base_address or somesuch) so that callers who want to show real virtual addresses can pass in `base' and callers who want to display relative offsets can pass in 0. OK, that's one way to do it. I'll wait a bit for other comments. Which implies that the address will need to be printed as a 16-digit number on 64-bit kernels. Yep. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
On Wed, 2 May 2007 15:35:56 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Based on ace_dump_mem() from Grant Likely for the Xilinx
> SystemACE CompactFlash interface.
>
> Add hex_dumper() to lib/hexdump.c and linux/kernel.h.
>
> This patch adds the function 'hex_dumper' which can be used to perform a
> hex + ASCII dump of data to syslog, in an easily viewable format, thus
> providing a common text hex dump format.
>
> It does not provide a hexdump_to_buffer() function.
> if someone needs that, we'll have to add it.
>
> Example usage:
> hex_dumper(KERN_DEBUG, data, length);
>
Fair enough. This is the sort of thing one could easily overdesign ;)
>
> include/linux/kernel.h |1
> lib/Makefile |2 -
> lib/hexdump.c | 51
> +
> 3 files changed, 53 insertions(+), 1 deletion(-)
>
> --- linux-2.6.21-git4.orig/include/linux/kernel.h
> +++ linux-2.6.21-git4/include/linux/kernel.h
> @@ -201,6 +201,7 @@ extern enum system_states {
> #define TAINT_USER (1<<6)
>
> extern void dump_stack(void);
> +extern void hex_dumper(const char *level, void *base, int len);
>
> #ifdef DEBUG
> /* If you are writing a driver, please use dev_dbg instead */
> --- linux-2.6.21-git4.orig/lib/Makefile
> +++ linux-2.6.21-git4/lib/Makefile
> @@ -5,7 +5,7 @@
> lib-y := ctype.o string.o vsprintf.o cmdline.o \
>rbtree.o radix-tree.o dump_stack.o \
>idr.o int_sqrt.o bitmap.o extable.o prio_tree.o \
> - sha1.o irq_regs.o reciprocal_div.o
> + sha1.o irq_regs.o reciprocal_div.o hexdump.o
>
> lib-$(CONFIG_MMU) += ioremap.o
> lib-$(CONFIG_SMP) += cpumask.o
> --- /dev/null
> +++ linux-2.6.21-git4/lib/hexdump.c
> @@ -0,0 +1,51 @@
> +/*
> + * lib/hexdump.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation. See README and COPYING for
> + * more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * hex_dumper - print a text hex dump to syslog for a binary blob of data
> + * @level: kernel log level (e.g. KERN_DEBUG)
> + * @buf: data blob to dump
> + * @len: number of bytes in the @buf
> + *
> + * Given a buffer of u8 data, hex_dumper() will print a hex + ASCII dump
> + * to the kernel log at the specified kernel log level.
> + *
> + * E.g.:
> + * hex_dumper(KERN_DEBUG, frame->data, frame->len);
> + *
> + * Prints the offsets of the block of memory, not addresses:
> + * 0009ab42: 40414243 44454647 48494a4b [EMAIL PROTECTED] HIJKLMNO
But I suspect it should be printing the addresses, for many callers.
In which case we'd need a separate arg (base_address or somesuch) so that
callers who want to show real virtual addresses can pass in `base' and
callers who want to display relative offsets can pass in 0.
Which implies that the address will need to be printed as a 16-digit number
on 64-bit kernels.
> + */
> +void hex_dumper(const char *level, void *base, int len)
> +{
> + const u8 *ptr = base;
> + int i, j;
> +
> + for (i = 0; i < len; i += 16) {
> + printk("%s%.8x:", level, i);
> + for (j = 0; (j < 16) && (i + j) < len; j++) {
> + if (!(j % 4))
> + printk(" ");
> + printk("%.2x", ptr[i + j]);
> + }
> + printk("-");
> + for (j = 0; (j < 16) && (i + j) < len; j++) {
> + printk("%c", isprint(ptr[i + j]) ? ptr[i + j] : '.');
> + if (j == 7)
> + printk(" ");
> + }
> + printk("\n");
> + }
> +}
> +EXPORT_SYMBOL(hex_dumper);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
On Wed, 2 May 2007 15:35:56 -0700
Randy Dunlap [EMAIL PROTECTED] wrote:
From: Randy Dunlap [EMAIL PROTECTED]
Based on ace_dump_mem() from Grant Likely for the Xilinx
SystemACE CompactFlash interface.
Add hex_dumper() to lib/hexdump.c and linux/kernel.h.
This patch adds the function 'hex_dumper' which can be used to perform a
hex + ASCII dump of data to syslog, in an easily viewable format, thus
providing a common text hex dump format.
It does not provide a hexdump_to_buffer() function.
if someone needs that, we'll have to add it.
Example usage:
hex_dumper(KERN_DEBUG, data, length);
Fair enough. This is the sort of thing one could easily overdesign ;)
include/linux/kernel.h |1
lib/Makefile |2 -
lib/hexdump.c | 51
+
3 files changed, 53 insertions(+), 1 deletion(-)
--- linux-2.6.21-git4.orig/include/linux/kernel.h
+++ linux-2.6.21-git4/include/linux/kernel.h
@@ -201,6 +201,7 @@ extern enum system_states {
#define TAINT_USER (16)
extern void dump_stack(void);
+extern void hex_dumper(const char *level, void *base, int len);
#ifdef DEBUG
/* If you are writing a driver, please use dev_dbg instead */
--- linux-2.6.21-git4.orig/lib/Makefile
+++ linux-2.6.21-git4/lib/Makefile
@@ -5,7 +5,7 @@
lib-y := ctype.o string.o vsprintf.o cmdline.o \
rbtree.o radix-tree.o dump_stack.o \
idr.o int_sqrt.o bitmap.o extable.o prio_tree.o \
- sha1.o irq_regs.o reciprocal_div.o
+ sha1.o irq_regs.o reciprocal_div.o hexdump.o
lib-$(CONFIG_MMU) += ioremap.o
lib-$(CONFIG_SMP) += cpumask.o
--- /dev/null
+++ linux-2.6.21-git4/lib/hexdump.c
@@ -0,0 +1,51 @@
+/*
+ * lib/hexdump.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation. See README and COPYING for
+ * more details.
+ */
+
+#include linux/types.h
+#include linux/ctype.h
+#include linux/kernel.h
+#include linux/module.h
+
+/**
+ * hex_dumper - print a text hex dump to syslog for a binary blob of data
+ * @level: kernel log level (e.g. KERN_DEBUG)
+ * @buf: data blob to dump
+ * @len: number of bytes in the @buf
+ *
+ * Given a buffer of u8 data, hex_dumper() will print a hex + ASCII dump
+ * to the kernel log at the specified kernel log level.
+ *
+ * E.g.:
+ * hex_dumper(KERN_DEBUG, frame-data, frame-len);
+ *
+ * Prints the offsets of the block of memory, not addresses:
+ * 0009ab42: 40414243 44454647 48494a4b [EMAIL PROTECTED] HIJKLMNO
But I suspect it should be printing the addresses, for many callers.
In which case we'd need a separate arg (base_address or somesuch) so that
callers who want to show real virtual addresses can pass in `base' and
callers who want to display relative offsets can pass in 0.
Which implies that the address will need to be printed as a 16-digit number
on 64-bit kernels.
+ */
+void hex_dumper(const char *level, void *base, int len)
+{
+ const u8 *ptr = base;
+ int i, j;
+
+ for (i = 0; i len; i += 16) {
+ printk(%s%.8x:, level, i);
+ for (j = 0; (j 16) (i + j) len; j++) {
+ if (!(j % 4))
+ printk( );
+ printk(%.2x, ptr[i + j]);
+ }
+ printk(-);
+ for (j = 0; (j 16) (i + j) len; j++) {
+ printk(%c, isprint(ptr[i + j]) ? ptr[i + j] : '.');
+ if (j == 7)
+ printk( );
+ }
+ printk(\n);
+ }
+}
+EXPORT_SYMBOL(hex_dumper);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
Andrew Morton wrote: On Wed, 2 May 2007 15:35:56 -0700 Randy Dunlap [EMAIL PROTECTED] wrote: From: Randy Dunlap [EMAIL PROTECTED] Based on ace_dump_mem() from Grant Likely for the Xilinx SystemACE CompactFlash interface. Add hex_dumper() to lib/hexdump.c and linux/kernel.h. This patch adds the function 'hex_dumper' which can be used to perform a hex + ASCII dump of data to syslog, in an easily viewable format, thus providing a common text hex dump format. It does not provide a hexdump_to_buffer() function. if someone needs that, we'll have to add it. Example usage: hex_dumper(KERN_DEBUG, data, length); Fair enough. This is the sort of thing one could easily overdesign ;) The Intel version also returned the number of bytes printed. and they had a hexdump_to_buffer() for sysfs output. include/linux/kernel.h |1 lib/Makefile |2 - lib/hexdump.c | 51 + 3 files changed, 53 insertions(+), 1 deletion(-) --- /dev/null +++ linux-2.6.21-git4/lib/hexdump.c @@ -0,0 +1,51 @@ +/** + * hex_dumper - print a text hex dump to syslog for a binary blob of data + * @level: kernel log level (e.g. KERN_DEBUG) + * @buf: data blob to dump + * @len: number of bytes in the @buf + * + * Given a buffer of u8 data, hex_dumper() will print a hex + ASCII dump + * to the kernel log at the specified kernel log level. + * + * E.g.: + * hex_dumper(KERN_DEBUG, frame-data, frame-len); + * + * Prints the offsets of the block of memory, not addresses: + * 0009ab42: 40414243 44454647 48494a4b [EMAIL PROTECTED] HIJKLMNO But I suspect it should be printing the addresses, for many callers. In which case we'd need a separate arg (base_address or somesuch) so that callers who want to show real virtual addresses can pass in `base' and callers who want to display relative offsets can pass in 0. OK, that's one way to do it. I'll wait a bit for other comments. Which implies that the address will need to be printed as a 16-digit number on 64-bit kernels. Yep. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
On Wed, 02 May 2007 15:56:48 -0700 Randy Dunlap [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Wed, 2 May 2007 15:35:56 -0700 Randy Dunlap [EMAIL PROTECTED] wrote: From: Randy Dunlap [EMAIL PROTECTED] Based on ace_dump_mem() from Grant Likely for the Xilinx SystemACE CompactFlash interface. Add hex_dumper() to lib/hexdump.c and linux/kernel.h. This patch adds the function 'hex_dumper' which can be used to perform a hex + ASCII dump of data to syslog, in an easily viewable format, thus providing a common text hex dump format. It does not provide a hexdump_to_buffer() function. if someone needs that, we'll have to add it. Example usage: hex_dumper(KERN_DEBUG, data, length); Fair enough. This is the sort of thing one could easily overdesign ;) The Intel version also returned the number of bytes printed. and they had a hexdump_to_buffer() for sysfs output. Yeah, that's where we get into creature feeping. Really it should be passed the address of a function which performs the per-char output and which is passed a bunch of args so it can do its stuff. But doing printk of a single char at a time is a bit inefficient and produces mangled output on SMP. And then we don't know the length of the output and we'd like it dynamically allocated and on and on. Ho hum. Perhaps a middle ground is to implement hexdump-to-memory as the core function. hex_dumper() becomes a simple wrapper around that. (but how big is its buffer? One line would be OK, I guess) OK, that's one way to do it. I'll wait a bit for other comments. Good luck ;) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/hexdump
On Wed, 2 May 2007 16:06:35 -0700 Andrew Morton wrote: On Wed, 02 May 2007 15:56:48 -0700 Randy Dunlap [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Wed, 2 May 2007 15:35:56 -0700 Randy Dunlap [EMAIL PROTECTED] wrote: From: Randy Dunlap [EMAIL PROTECTED] Based on ace_dump_mem() from Grant Likely for the Xilinx SystemACE CompactFlash interface. Add hex_dumper() to lib/hexdump.c and linux/kernel.h. This patch adds the function 'hex_dumper' which can be used to perform a hex + ASCII dump of data to syslog, in an easily viewable format, thus providing a common text hex dump format. It does not provide a hexdump_to_buffer() function. if someone needs that, we'll have to add it. Example usage: hex_dumper(KERN_DEBUG, data, length); Fair enough. This is the sort of thing one could easily overdesign ;) The Intel version also returned the number of bytes printed. and they had a hexdump_to_buffer() for sysfs output. Yeah, that's where we get into creature feeping. Really it should be passed the address of a function which performs the per-char output and which is passed a bunch of args so it can do its stuff. But doing printk of a single char at a time is a bit inefficient and produces mangled output on SMP. And then we don't know the length of the output and we'd like it dynamically allocated and on and on. Ho hum. Perhaps a middle ground is to implement hexdump-to-memory as the core function. hex_dumper() becomes a simple wrapper around that. (but how big is its buffer? One line would be OK, I guess) Yeah, I almost did it that way. We'll see. OK, that's one way to do it. I'll wait a bit for other comments. Good luck ;) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
