linux-kernel - Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

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, 25 Apr 2021 10:33:57 +0300
From:   Mike Rapoport <rppt@...nel.org>
To:     Peter.Enderborg@...y.com
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        sumit.semwal@...aro.org, christian.koenig@....com,
        adobriyan@...il.com, akpm@...ux-foundation.org,
        songmuchun@...edance.com, guro@...com, shakeelb@...gle.com,
        mhocko@...e.com, neilb@...e.de, samitolvanen@...gle.com,
        linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linaro-mm-sig@...ts.linaro.org, willy@...radead.org
Subject: Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

On Thu, Apr 22, 2021 at 02:08:51PM +0000, Peter.Enderborg@...y.com wrote:
> On 4/22/21 10:06 AM, Mike Rapoport wrote:
> > So the flow is like this:
> >
> > * a user has a problem and reports it to an application developer; at best
> >   the user runs simple and limited app to collect some data
> > * if the application developer considers this issue as a system related
> >   they can open adb and collect some more information about the system
> >   using non-root shell with selinux policy restrictions and send this
> >   information to the device manufacturer.
> > * the manufacturer continues to debug the issue and at this point as much
> >   information is possible would have been useful.
> >
> > In this flow I still fail to understand why the manufacturer cannot provide
> > userspace tools that will be able to collect the required information.
> > These tools not necessarily need to target the end user, they may be only
> > intended for the application developers, e.g. policy could allow such tool
> > to access some of the system data only when the system is in developer
> > mode.
> >
> The manufacture is trying to get the tool to work. This is what the
> patch is about. Even for a application developer a commercial
> phone is locked down.

Right, but it's still in full control of the manufacturer what's flashed
there, isn't it?
So there could be some tools that are only available in the developer mode?
These tools could have different permissions etc.

> Many vendors allow that you flash some other software like a AOSP.  But
> that can be very different. Like installing a ubuntu on a PC to debug a
> Fedora issue.
> 
> And sure we can pickup parts of what using the dma-buf. But
> we can not get the total and be sure that is the total without a
> proper counter.

If I understand you correctly, a user space tool that scans fdinfo and
accumulates dma-buf size from there is not accurate enough, that's why an
atomic counter exposed by kernel is a must.

But if the changes in consumption of dma-bufs are that frequent, I cannot
see how a global counter will help to identify an issue.

And if this counter is needed to see if there is a memory leak, summing
sizes of dma-bufs from fdinfo will identify a leak.

What am I missing?

-- 
Sincerely yours,
Mike.