linux-kernel - Re: [PATCH/RFC] ummunot: Userspace support for MMU notifications

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:	Thu, 23 Jul 2009 13:28:01 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Jeff Squyres <jsquyres@...co.com>
Subject: Re: [PATCH/RFC] ummunot: Userspace support for MMU notifications


 > This can be implemented as a tracer or trace events, though I'm
 > not sure if it can fully meet your requirements or not.
 > 
 > To implement it as trace events, we add tracepoints in mmu_inlivadate_xxx(),
 > and define some TRACE_EVENT() macros.
 > 
 > And below shows how to use it:
 > 
 >   # mount -t debugfs xxx /mnt
 >   # cd /mnt/tracing/
 >   # echo 1 > events/mmu/enable
 >   # echo '(start >= 10000000 && end <= 10004096) || \
 > 	(start >= 20000000 && end <= 20004096)' > events/mmu/filter
 >   # cat trace_pipe
 >         bash-2066  [001]   795.239077: mmu_invalidate_range_start: start=10000000 end=10000100
 >         bash-2066  [001]   795.239091: mmu_invalidate_range_start: start=10000000 end=10000100
 >         bash-2066  [001]   795.239098: mmu_invalidate_range_start: start=10000000 end=10000100
 >          cat-2189  [001]   795.239502: mmu_invalidate_page: start=20000000 end=20003000
 >          cat-2189  [001]   795.239578: mmu_invalidate_page: start=20000000 end=20003000
 >         bash-2066  [001]   795.239626: mmu_invalidate_page: start=20000000 end=20003000
 > 
 > The patch is extremely simple:

Thanks... unfortunately I don't think this really helps for the use case
I'm trying to address.  What's desired is a way for an unprivileged
userspace process to monitor (parts of) its own address space; I think
getting a single stream of all such events is not going to be helpful,
because, first, the overhead of filtering out the subset of useful
events may be too high to make this useful and, second, exposing events
about unrelated processes is probably a security hole (eg "allocation
channel" attacks on crypto processes analogous to timing channel attacks)

If there were some way for each process to get a trace of its own events
then that would be very close to what I'm trying to implement.

Thanks,
  Roland
--
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/