Re: KAUTH_PROCESS_SCHEDULER_*AFFINITY restricted to root in default secmodel?

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

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.migeon%free.fr@localhost