linux-kernel - perf synthesized mmap timeouts

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-next>] [day] [month] [year] [list]

Message-Id: <20181027.214102.1558835285408950686.davem@davemloft.net>
Date:   Sat, 27 Oct 2018 21:41:02 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     acme@...nel.org
CC:     linux-kernel@...r.kernel.org, kan.liang@...el.com
Subject: perf synthesized mmap timeouts

If I understand the commit message for:

commit 8cc42de736b617827a4e7664fb8d7a325bc125bc
Author: Kan Liang <kan.liang@...el.com>
Date:   Thu Jan 18 13:26:32 2018 -0800

    perf top: Check the latency of perf_top__mmap_read()

properly, the problem is that a malicious or out of control
app can be doing endless mmaps causing perf to loop forever
processing the /proc/$PID/maps file.

But that is not what this commit is handling at all.

It is instead applying a large hammer which quits if it is taking a
long time to process the maps, not if the process's mmap list is
growing endlessly while we process it.

This triggers any time I run perf top on a fully loaded system making
perf less useful than it should be.

And it triggers simply because the perf synthesize threads have to
share the cpu with the workload already running.

So it takes more than half a second to process emacs's 527 maps when
the number of running processes is ~NCPUS?  Big deal.  We should let
it finish....

The tradeoff choosen here is really bad.

Guess what happens if you don't have maps for a given process?

What happens is that for every single sample we get within that range,
we get a completely unique histogram entry.

This means potentially millions and millions of histogram entries
where there should only be a few hundred.

This makes the histogram rbtree huge, and slow to process.

So not only is top unable to provide correct histogram output, it is
also running sluggishly.

A way to mitigate the actual problem would be to snapshot the maps
file into a large buffer, if possible.  We can get the full contents
faster than the process in question can make more maps.  At most we
will do one additional read at the end if they were able to sneak in
one new mmap during the initial read.

No timeout necessary.  We have the complete maps file, our processing
time is therefore bounded.

Thanks.