linux-kernel - Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups

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: <20070413171308.GP11115@waste.org>
Date:	Fri, 13 Apr 2007 12:13:08 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	William Lee Irwin III <wli@...omorphy.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups

On Fri, Apr 13, 2007 at 12:18:56PM +1000, Nick Piggin wrote:
> Can't you just traverse arbitrary kernel data structures at a given point
> in time, exactly like the /proc/ call is doing?

Perhaps.

My understanding is that you hook a kprobe to an event. An event is a
particular instruction getting executed. Indeed, you can do whatever
poking around in the kernel you want at that point. And then you can
stuff that data in a buffer that eventually gets to userspace.

This is very different from a read/seek/syscall. Rather than just
asking the kernel for some data, we have to wait for the relevent
events. Now, of course, you can make an ugly hack like hooking
sys_getpid() and basically make your own system call. Hopefully no one
else will call getpid() while you're doing this, etc. Not really how
it's intended to work at all, and probably a bitch to use, but
possible. Then the question becomes: why don't we do this for
everything else in /proc?

And the answer of course is: we put stuff in /proc because it's
generally useful. Extra points if it's actually related to
'proc'esses. Being able to tell what's paged in in a given mapping is
useful. Being able to tell what's shared between two mappings is
useful. Being able to get an accurate, meaningful picture of how your
memory is being used is useful. Heck, I bet some people might find it
useful to be able to see what nodes the pages in their process are on.
All stuff you shouldn't need to be a kernel hacker to answer.

The flags part of /proc/kpagemap exposes some (very interesting!)
implementation details. The rest of it is completely generic to any
system with a VM. It's only deep kernel magic in the sense that it's
not yet exposed.

-- 
Mathematics is the supreme nostalgia of our time.
-
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/