linux-kernel - Re: [RFC 0/6] Module for tracking/accounting shared memory buffers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161012002634.GN19539@ZenIV.linux.org.uk>
Date:   Wed, 12 Oct 2016 01:26:34 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Ruchi Kandoi <kandoiruchi@...gle.com>
Cc:     gregkh@...uxfoundation.org, arve@...roid.com,
        riandrews@...roid.com, sumit.semwal@...aro.org, arnd@...db.de,
        labbott@...hat.com, jlayton@...chiereds.net, bfields@...ldses.org,
        mingo@...hat.com, peterz@...radead.org, akpm@...ux-foundation.org,
        keescook@...omium.org, mhocko@...e.com, oleg@...hat.com,
        john.stultz@...aro.org, mguzik@...hat.com, jdanis@...gle.com,
        adobriyan@...il.com, ghackmann@...gle.com,
        kirill.shutemov@...ux.intel.com, vbabka@...e.cz,
        dave.hansen@...ux.intel.com, dan.j.williams@...el.com,
        hannes@...xchg.org, iamjoonsoo.kim@....com, luto@...nel.org,
        tj@...nel.org, vdavydov.dev@...il.com, ebiederm@...ssion.com,
        linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
        linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linaro-mm-sig@...ts.linaro.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [RFC 0/6] Module for tracking/accounting shared memory buffers

On Tue, Oct 11, 2016 at 04:50:04PM -0700, Ruchi Kandoi wrote:

> memtrack maintains a per-process list of shared buffer references, which is
> exported to userspace as /proc/[pid]/memtrack.  Buffers can be optionally
> "tagged" with a short string: for example, Android userspace would use this
> tag to identify whether buffers were allocated on behalf of the camera stack,
> GL, etc.  memtrack also exports the VMAs associated with these buffers so
> that pages already included in the process's mm counters aren't double-counted.
> 
> Shared-buffer allocators can hook into memtrack by embedding
> struct memtrack_buffer in their buffer metadata, calling
> memtrack_buffer_{init,remove} at buffer allocation and free time, and
> memtrack_buffer_{install,uninstall} when a userspace process takes or
> drops a reference to the buffer.  For fd-backed buffers like dma-bufs, hooks in
> fdtable.c and fork.c automatically notify memtrack when references are added or
> removed from a process's fd table.
> 
> This patchstack adds memtrack hooks into dma-buf and ion.  If there's upstream
> interest in memtrack, it can be extended to other memory allocators as well,
> such as GEM implementations.

No, with a side of Hell, No.  Not to mention anything else,
	* descriptor tables do not belong to any specific task_struct and
actions done by one show up in all who share that thing.
	* shared descriptor table does not imply belonging to the same
group.
	* shared descriptor table can become unshared at any point, invisibly
for that Fine Piece Of Software.
	* while we are at it, blocking allocation under several spinlocks
(and with interrupts disabled, for good measure) is generally considered
a bloody bad idea.

That - just from the quick look through that patchset.  Bringing task_struct
into the API is already sufficient for a NAK.