cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c

[Nate Lawson]

Colin Percival wrote:
> Maxim Sobolev wrote:
>> By the way, I wonder how sun4v (aka Niagara) fares in this respect. As
>> long as I know, they use similar concept, when 8 physical cores can run
>> 32 threads. Should we disable it by default there as well? ;-)
> 
> I haven't seen any experiments done on sun4v, but I'm less concerned about
> it since I believe sun4v boxes are used more often for large computing jobs
> rather than for interactive logins with many untrusted users.  Of course,
> if/when we have scheduler support for keeping different users on separate
> cores, this should be applied to sun4v as well.

I don't think locking threads to cores by uid solves the general
problem.  Consider a web server, where processes run as the same uid but
represent different customers.  What we need is for the software
components that deal with secrets (keys, passwords, etc.) to be able to
specify "don't switch me out until I'm done" for a short quantum.
Restricting access to that mechanism would also be needed to prevent
DoS, same as realtime scheduling.

-- 
Nate