On 28.08.2011 22:03, Jeff Rizzo wrote: > I've just had my first occasion to play with the processor affinity > code, via porting some code from linux. It was very straightforward, > but there's one glaring difference: linux doesn't (by default, anyway) > require root to use their sched_setaffinity(), while we do require root > (by default) for pthread_setaffinity_np(). > > I don't pretend to understand the security ramifications regarding > processor affinity; I do wonder, however, whether it warrants requiring > elevated privilege (and possible exposure via other code in the process > which doesn't require root for normal operation) to prevent allowing > users to pin their own code to a particular cpu by default. Are we sure > we've made the right (default) tradeoff here?
I think so. In a more broad thinking about resources, letting consumers have some form of control on producers is always problematic. At least when you have to deal with availability (which is a security concern BTW). For that particular case, if you want a specific example of why this can be problematic, have a look at an article written by Colin (Percival) a while back [1]. It's a proof of concept regarding a side channel that could be used to obtain information about another process when both are executing in a specific context (shared caches, like for hyperthreading in his article). Giving a LWP the right to pin to a certain CPU here is very bad: for example, with adequate time measurements you can obtain private RSA keys when used for calculation. [1] http://www.daemonology.net/papers/htt.pdf -- Jean-Yves Migeon jeanyves.mig...@free.fr