tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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.


Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index