linux-kernel - Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer

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]

Date:	Sun, 27 May 2012 16:23:17 +0200
From:	Kay Sievers <kay@...y.org>
To:	Anton Vorontsov <anton.vorontsov@...aro.org>
Cc:	Greg Kroah-Hartmann <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Kees Cook <keescook@...omium.org>,
	Colin Cross <ccross@...roid.com>,
	Tony Luck <tony.luck@...el.com>,
	John Stultz <john.stultz@...aro.org>
Subject: Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length
 record buffer

On Sat, May 26, 2012 at 1:11 PM, Anton Vorontsov
<anton.vorontsov@...aro.org> wrote:

>> Subject: printk: convert byte-buffer to variable-length record buffer
>
> Bad news, this patch breaks all kmsg_dump users.
>
> Per current printk.c:
>
>  * The 'struct log' buffer header must never be directly exported to
>  * userspace, it is a kernel-private implementation detail that might
>  * need to be changed in the future, when the requirements change.
>
> But kmsg_dump users get the raw log, not text. Some users may even
> use strlen() on the buffers, e.g. ramoops module was using it just
> recently, before persistent_ram rework.
>
> So, starting from this patch every kmsg_dump user is getting the
> binary stuff, which is barely usable, and breaks a longstanding
> user-visible ABIs (e.g. mtdoops, oops dumping into nvram on PowerPC,
> and ramoops of course).

These cases export their own format, it's just that the dump routines
could copy the buffer in only two steps (beginning and end of the ring
buffer), while in the future their code would need an update to copy
it record for record now. The exported format in the dump does not
necessarily need to change.

It should be possible to convert them pretty easily to do that, they
operate on their own allocated buffers already. Some of them seem to
mangle the line-buffer already, so they should be able to copy
record-by-record either.

> I'm not sure how we can fix this without allocating a huge buffer
> (and thus wasting memory), or reworking the whole kmsg_dump concept
> and its users.

I think an iterator in the dumper code is nicer and simpler. It will
even provide structured data to the dumper, if the dumper wants to
make use of it in the future. The prefix mangling of the text in the
nvram dumper could surely benefit from that.

The iterator would basically work similar to the printing of the whole
buffer at a newly registered boot console, which was doing a similar
logic as the dumper does.

> p.s. And, btw, during HW bring-up, when there's even no serial
> console usable, I somewhat liked to directly print log_buf memory
> from a JTAG debugger, and thus see the kernel logs. Now that'll
> look ugly. Heh. :-)

Yeah, that probably does not look pretty anymore, but it still all
works, right? Doesn't have he debugger a strings(1)-like output to
print of a memory area?

Kay
--
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/