Re: [lmi] perf

[Greg Chicares]

On 2020-09-27 18:44, Greg Chicares wrote:
> On 2020-09-27 17:57, Vadim Zeitlin wrote:
>> On Sat, 26 Sep 2020 23:14:21 +0000 Greg Chicares <gchicares@sbcglobal.net> 
>> wrote:
>> 
>> GC> My normal user doesn't have CAP_SYS_ADMIN. Apparently if you have
>> GC> that, you're almost root anyway, so I'm reluctant to give myself
>> GC> that privilege--at least when I become root, I'm aware that I need
>> GC> to be especially careful. Do you use root, or grant your normal
>> GC> user CAP_SYS_ADMIN, or run 'perf' in some other way?
>> 
>>  I just do what, I think, it told me to do, once I've tried using it
>> unsuccessfully, i.e. set kernel.perf_event_paranoid kernel parameter to 0
>> or -1 depending on my current actual level of paranoia. This can, of
>> course, be done temporarily, if you run perf only episodically.
>> 
>>  FWIW I definitely don't run perf as root -- not because I don't trust perf
>> itself, but because I don't trust my own programs, that would also run as
>> root then.
> 
> Oh. I didn't think of that. I guess that 'paranoid' thing is the
> least dangerous option.

For the record...I tried the latest official advice:
  https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
which doesn't use CAP_SYS_ADMIN:

# cd /usr/bin 
# groupadd perf_users
# chgrp perf_users perf
# chmod o-rwx perf
# ls -l perf
-rwxr-x--- 1 root perf_users 528 Jul 20  2018 perf
# setcap "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" perf
fatal error: Invalid argument
# setcap "38,cap_ipc_lock,cap_sys_ptrace,cap_syslog=ep" perf
# setcap -v "38,cap_ipc_lock,cap_sys_ptrace,cap_syslog=ep" perf
perf: OK
# getcap perf
perf = cap_ipc_lock,cap_sys_ptrace,cap_syslog,38+ep
# usermod -aG perf_users greg

My normal user was already logged in, and 'groups' didn't show
my newly-added membership in 'perf_users', so I tried...

$ newgrp perf_users

but 'perf' still gave
  error 13 (Permission denied) ...
  Consider tweaking /proc/sys/kernel/perf_event_paranoid

so I fell back on...

# echo 1 >/proc/sys/kernel/perf_event_paranoid

and was able to use 'perf'.

Maybe kernel.org's advice will work when I eventually log out
and back in again.

>> GC> the seemingly brilliant idea of running 'perf' in my host
>> GC> (after installing it successfully there) to profile a binary
>> GC> in a chroot:
[...]
> [...and hilarity ensues...]
> 
>>  I don't really know what's going on here, but trying to run a binary from
>> chroot outside of chroot just seems weird. OTOH I still think you ought to
>> be able to run "perf record schroot -c bullseye0 /path/to/lmi_cli_shared"
>> or something like this, shouldn't you?
> 
> Thanks, I didn't think of that.

Perhaps chroots are just incompatible with 'perf'. This works:

$perf record -e cpu-clock sleep 1                        
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.017 MB perf.data (3 samples) ]
$perf report --stdio             

(the output is valid, even though it has little to say), but this fails:

$perf record -e cpu-clock -- schroot -c bullseye0 sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.017 MB perf.data ]
zsh: terminated  perf record -e cpu-clock -- schroot -c bullseye0 sleep 1
$perf report --stdio                             
Error:
The perf.data file has no samples!

For the record (because it was hard to figure out), this command:

$schroot -c bullseye0 -- sh -c 
'LD_LIBRARY_PATH=/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship 
/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/lmi_cli_shared --accept 
--data_path=/opt/lmi/data --selftest'

really does run a self-test, but trying to use it with 'perf'
fails with "zsh: terminated" as for the chroot 'sleep' above.

Then I had another idea that seemed brilliant--on my host,
try executing a program that resides in the chroot with an
LD_LIBRARY_PATH that includes a path to everything found
by running 'ldd' on that program. But that segfaulted,
even without 'perf':

$ chrtpath=/srv/chroot/bullseye0 ; 
lmipath=$chrtpath/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship ; 
LD_LIBRARY_PATH="$lmipath:$chrtpath/lib/x86_64-linux-gnu:$chrtpath/lib64/" 
$lmipath/lmi_cli_shared --accept --data_path=/opt/lmi/data --selftest
zsh: segmentation fault  
LD_LIBRARY_PATH="$lmipath:$chrtpath/lib/x86_64-linux-gnu:$chrtpath/lib64/"

My next step will be to compile lmi on the host. I haven't
installed gcc there yet, but 'buster' has gcc-8.3.0-1, which
should be good enough for now. For std::filesystem, we'll need
gcc-10, which is in 'bullseye', and I'm sure it can't be too
hard to install that in 'buster'.