On 14.12.2016 08:00, Andreas Schäfer wrote:
On 14:24 Mon 12 Dec , Dave Love wrote:
Andreas Schäfer <gent...@gmx.de> writes:
Yes, as root, and there are N different systems to at least provide
unprivileged read access on HPC systems, but that's a bit different, I
think.
LIKWID[1] uses a daemon to provide limited RW access to MSRs for
applications. I wouldn't wonder if support for this was added to
LIKWID by RRZE.
Yes, that's one of the N I had in mind; others provide Linux modules.
From a system manager's point of view it's not clear what are the
implications of the unprivileged access, or even how much it really
helps. I've seen enough setups suggested for HPC systems in areas I
understand (and used by vendors) which allow privilege escalation more
or less trivially, maybe without any real operational advantage. If
it's clearly safe and helpful then great, but I couldn't assess that.
I think LIKWID's access daemon is specifically designed to provide a
safe way of giving limited access to MSRs. I'm cc'ing Thomas Röhl as
he knows more about this.
As Andreas stated, the access daemon was written providing a rather safe
method for users to access the MSRs. It opens a UNIX socket to
communicate with the actual application. The lists of allowed registers
are compiled inside the daemon, so no changes can be done from the
outside and users are limited to the allowed registers. The code was
checked by an IT security team and all recommendations were integrated
but there are possibly other bugs (like in any other code).
If a user wants to dig deep into his/her code or control the behavior of
a machine, providing access to MSR for users is really helpful. The
LIKWID suite contains some examples like controlling CPU frequencies,
(de)activating various hardware prefetchers or configuring the power
budget.
For system manger's, the user access to MSRs can be a real pain because
all MSRs need to be checked before/after a user's work to provide the
system in a consistent state to the next user. Moreover, for both kernel
modules and a privilege escalating daemon, there is commonly a reduction
of security that must be compared to the possible advantages. My
experience shows that system manager's don't want to load third-party
kernel modules on their in-production systems (as long as there is no
big company behind) but they also don't trust a suid-root daemon as the
one of LIKWID.
For a runtime management system as OpenMPI, the integration of libcap is
probably the safest way to access to the MSRs. You don't need a daemon
and the application keeps running with common user privileges. The
handling of libcap can be somewhat annoying and was Linux distribution
dependent at the time I checked it (some worked, some not, some showed
completely undefined behavior).
Cheers,
Thomas
--
--
M.Sc. Thomas Roehl, HPC Services
Friedrich-Alexander-Universitaet Erlangen-Nuernberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstrasse 1, 91058 Erlangen, Germany
Tel. +49 9131 85-20800
mailto:thomas.ro...@rrze.fau.de
http://www.hpc.rrze.uni-erlangen.de/
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
