is MSR access in only-read mode safe?

[hervem]

Hello,

I developed a tool based on  (Linux) rdmsr to read some MSR registers (RAPL). And I would like to have this tool installed on large computing clusters.

I know that allowing read AND write of MSR registers for all the users is not safe, mainly due to the write capability.

I suppose that allowing only read (even for all users) is safe, but I failed to find literature on it.

Is there any? Is it obvious?

Thanks in advance for your help,

hervem

[McCalpinJohn]

"Safe" can mean several different things in this context....

Write access to MSRs can fairly easily crash a system.  Read access to MSRs should not be able to crash a system.

Read access to MSRs opens a fair number of security risks.

The project https://github.com/LLNL/msr-safe provides the ability grant different permissions to different MSRs.  Limiting the accessible MSRs to the ones of interest can reduce the uncertainty about security risks.  I have not deployed this package on production systems, but had no trouble getting it to work properly on a test cluster.

[hervem]

Thanks for your help.

I agree, msr-safe is a good candidate to limit the risks. I did not use it yet. 

BTW
In HPC context the users allocate usually nodes with exclusivity access (not shared).
NB : If the node is not allocated in an exclusive mode, you can have a look on what is running on the node (from yourself or not), with or without msr_read.

So safe could be understood as :
By using (only) msr_read, can we access information we should not access as a basic user (eg password, code&data of other users) ? or can we modify the cluster behavior ?
I would say NO, but perhaps I am wrong.

[urimashi]

Hello McCalpinJohn,

What are the risks for read access to the MSRs?

Thanks,

Uri

[McCalpinJohn]

I routinely read all the MSRs on systems to document the system state -- this has never caused any crashes or misbehavior, so it is "safe" in that limited sense.

Read access to MSRs is "unsafe" in the sense of system security.  It allows any user with access to read a whole lot of state that is supposed to be private to the OS or to other users.  I don't know of any specific exploits that I could name, but some of the problematic content includes:

• Read the core performance counter programming and performance counter values on any core.
• Read the CHA/SF/LLC performance counter programming and counter values for any CHA/SF/LLC block.
• Machine Check Architecture records
  • (May help with RowHammer-type attacks?)