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

[Juli Mallett]

* Nate Lawson <nate at root.org> [ 2007-11-11 ]
	[ Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c ]
> 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.

If you really want to do that sort of thing, I don't think you want to trust
userland code with it.  You could put the sensitive parts of crypto routines in
the kernel and run them in a critical section, but I'm not sure it's worth it.
We could also let a process request that if we do context switch it out, we
cover its tracks a little, assuming we can come up with a mechanism to do that
(whether there's a direct one or whether we have to have some code that does
some nonsense to overwrite whatever caches.)  You could even give such a process
a shorter quantum to account for the extra time that would need spent
immediately after context switching out from it.  If it's doable, that seems far
better to any specialization of the code or requiring any sort of extra
credentials.  Doesn't solve the HTT case, though.  If we were to just move the
compromisable functionality to the kernel, it would be easy for it to require
that any cores which share its branch prediction table, caches, etc., not have
anything running at the time it goes into its critical section.