linux-kernel - Re: [PATCH v10 Golden] Unified trace 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:	Tue, 30 Sep 2008 09:38:18 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Jonathan Corbet <corbet@....net>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com, "Frank Ch. Eigler" <fche@...hat.com>,
	David Wilder <dwilder@...ibm.com>, hch@....de,
	Martin Bligh <mbligh@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Steven Rostedt <srostedt@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCH v10 Golden] Unified trace buffer

On Tue, 30 Sep 2008, Peter Zijlstra wrote:
> 
> Its not that complex IMHO, the thing that is ugly are those struct page
> overloads, what we could do is try and sanitize the regular struct page
> and pull all these things in.

That's not the scary part. The scary part is that somebody may well want 
to access the trace buffer pages in complex ways.

If you mmap them, for example, you can use VM_PFNMAP to make sure that 
nobody should ever look at the "struct page", but if you want to do things 
like direct-to-disk IO on the trace pages (either with splice() or with 
some kind of in-kernel IO logic), then you're officially screwed.

> Because the only reason people are doing these overloads is because
> struct page in mm_types.h is becomming an unreadable mess.

The "unreadable mess" has exactly the same issues, though: people need to 
realize that when you overload fields in the page structure, you can then 
NEVER EVER use those pages for any other thing. 

For the internal VM code, that's ok. The VM knows that a page is either an 
anonymous page or a file mapping etc, and the overloading wrt mm_types.h 
is explicit. The same goes for SL*B, although it does the overloading 
differently.

Trace buffers are different, though. Do people realize that doing the 
overloading means that you never EVER can use those buffers for anything 
else? Do people realize that it means that splice() and friends are out of 
the question?

> Trouble is, looking at it I see no easy way out,

Quite frankly, we could just put it at the head of the page itself. Having 
a "whole page" for the trace data is not possible anyway, since the trace 
header itself will always eat 8 bytes.

And I do think it would potentially be a better model. Or at least safer.

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