Le 15/06/2017 à 11:01, Manuel Bouyer a écrit :
On Thu, Jun 15, 2017 at 10:51:34AM +0200, Maxime Villard wrote:
Le 15/06/2017 à 10:28, Manuel Bouyer a écrit :
On Thu, Jun 15, 2017 at 10:11:21AM +0200, Maxime Villard wrote:
There were several strong objections to our change in this thread: http://mail-index.netbsd.org/tech-kern/2017/03/28/msg021705.html
Man, that's another thread. My commit is about PMCs, not rdtsc.
OK I got confused. then where was this change discussed ?
nowhere
IHMO the same arguments from the thread applies here.
Which argument? fyi, pmcs are not enabled by default, and until a few months ago they didn't even work. I'm making them privileged with the intention of enabling them for real. The reasons we need root privileges are: the msr values are given by userland and we don't want unprivileged users to panic the system, and more generally, pmcs can be used to defeat aslr (as said in the thread, btw).
So, it a user wants to use the PMCs to tune a code, I have to give him root access.
Basically, right now, yes. But that's still better than no PMCs at all.
I can't see how this improves the security. AFAIK on linux PMCs can be used without root.
We don't do application tracking, contrary to linux. That is, we don't save/restore the counters on context switch. So the average user will have only little interest in PMCs. Verily the current implementation is mainly useful to measure the kernel itself; when you make a change, and want to see whether the hit/miss ratios are improved. So yes, our implementation is not very useful. Also, we support only few CPUs. But as I said it's still better than nothing, and so far I appear to have been the only one that has shown (some) interest in developing this.