[PATCH] Sample fix for hyperthread exploit

[PATCH] Sample fix for hyperthread exploit

[Con Kolivas]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

With respect to the recently publicised theoretical exploit for tasks running 
on hyperthread siblings, we already have in our hyperthreading code the 
ability to suspend running of tasks on siblings based on their behaviour. We 
could extend that if so desired as a plug for this theoretical exploit. We 
could suspend tasks that run on siblings based on their uid to prevent 
another user from being able to instrument cache misses from another user's 
task. Attached is a sample patch to do just that. It is my understanding that 
this exploit is not deemed significant risk anyway, and the attached solution 
would cost us in throughput if multiple users' tasks are running 
concurrently, but would still be better than disabling hyperthreading. This 
patch is more for discussion than inclusion, and is otherwise untested.

Comments?

Signed-off-by: Con Kolivas <kernel@kolivas.org>


[-- Attachment #2: dependent_sleep_on_uid.diff --]
[-- Type: text/x-diff, Size: 1012 bytes --]

Index: linux-2.6.12-rc5-uiddep/kernel/sched.c
===================================================================
--- linux-2.6.12-rc5-uiddep.orig/kernel/sched.c	2005-05-29 19:54:30.000000000 +1000
+++ linux-2.6.12-rc5-uiddep/kernel/sched.c	2005-06-01 21:46:54.000000000 +1000
@@ -2530,6 +2530,21 @@ static inline int dependent_sleeper(int 
 		task_t *smt_curr = smt_rq->curr;
 
 		/*
+		 * Don't let tasks from different users run on siblings that
+		 * share caches to avoid the security risk of cache misses.
+		 * If an equal priority task is already running let that one
+		 * continue, otherwise let only the better priority task run.
+		 */
+		if (p->uid != smt_curr->uid && p->mm && smt_curr->mm) {
+			if (smt_curr->prio <= p->prio) {
+				ret = 1;
+				continue;
+			}
+			resched_task(smt_curr);
+			continue;
+		}
+
+		/*
 		 * If a user task with lower static priority than the
 		 * running task on the SMT sibling is trying to schedule,
 		 * delay it till there is proportionately less timeslice

Re: [PATCH] Sample fix for hyperthread exploit

[Arjan van de Ven]

> Comments?

I don't think it's really worth it, but if you go this way I'd rather do
this via a prctl() so that apps can tell the kernel "I'd like to run
exclusive on a core". That'd be much better than blindly isolating all
applications.

Re: [PATCH] Sample fix for hyperthread exploit

[Con Kolivas]

On Wed, 1 Jun 2005 22:06, Arjan van de Ven wrote:
> > Comments?
>
> I don't think it's really worth it, but if you go this way I'd rather do
> this via a prctl() so that apps can tell the kernel "I'd like to run
> exclusive on a core". That'd be much better than blindly isolating all
> applications.

I agree, and this is where we (could) implement the core isolation. I'm still 
under the impression (as you appear to be) that this theoretical exploit is 
not worth trying to work around.

Cheers,
Con

Re: [PATCH] Sample fix for hyperthread exploit

[Chris Wright]

* Con Kolivas (kernel@kolivas.org) wrote:
> On Wed, 1 Jun 2005 22:06, Arjan van de Ven wrote:
> > > Comments?
> >
> > I don't think it's really worth it, but if you go this way I'd rather do
> > this via a prctl() so that apps can tell the kernel "I'd like to run
> > exclusive on a core". That'd be much better than blindly isolating all
> > applications.
> 
> I agree, and this is where we (could) implement the core isolation. I'm still 
> under the impression (as you appear to be) that this theoretical exploit is 
> not worth trying to work around.

Also, uid is not sufficient.  Something more comprehensive (like ability
to ptrace) would be appropriate.

thanks,
-chris

Re: [PATCH] Sample fix for hyperthread exploit

[Arjan van de Ven]

On Wed, 2005-06-01 at 10:25 -0700, Chris Wright wrote:
> * Con Kolivas (kernel@kolivas.org) wrote:
> > On Wed, 1 Jun 2005 22:06, Arjan van de Ven wrote:
> > > > Comments?
> > >
> > > I don't think it's really worth it, but if you go this way I'd rather do
> > > this via a prctl() so that apps can tell the kernel "I'd like to run
> > > exclusive on a core". That'd be much better than blindly isolating all
> > > applications.
> > 
> > I agree, and this is where we (could) implement the core isolation. I'm still 
> > under the impression (as you appear to be) that this theoretical exploit is 
> > not worth trying to work around.
> 
> Also, uid is not sufficient.  Something more comprehensive (like ability
> to ptrace) would be appropriate.

I would go a lot simpler. App says "I want exclusivity" via pctl and
NOTHING runs on the other half. Well maybe with exceptions of processes
that share the mm with the exclusive one (in practice "threads") since
those could just read the memory anyway.

ptrace-ability goes wonky the moment the "secret bearing" thread revokes
something that would make ptrace be denied consequently ... means we'd
have to find all those cases and make all of them bump the other app of
the cpu. smells too complex to me for such a rare event -> hard to get
fail proof.

Re: [PATCH] Sample fix for hyperthread exploit

[Ingo Molnar]

* Arjan van de Ven <arjan@infradead.org> wrote:

> > Also, uid is not sufficient.  Something more comprehensive (like ability
> > to ptrace) would be appropriate.
> 
> I would go a lot simpler. App says "I want exclusivity" via pctl and 
> NOTHING runs on the other half. Well maybe with exceptions of 
> processes that share the mm with the exclusive one (in practice 
> "threads") since those could just read the memory anyway.

this has the disadvantage of needing changes in the security apps.  
Basing this off the uid (or the ability to ptrace) makes it at least 
automatic - but introduces a permanent penalty not only on multiuser 
boxes, but on basically any server box that runs multiple services.

	Ingo

Re: [PATCH] Sample fix for hyperthread exploit

[Con Kolivas]

On Thu, 2 Jun 2005 12:49 pm, Ingo Molnar wrote:
> * Arjan van de Ven <arjan@infradead.org> wrote:
> > > Also, uid is not sufficient.  Something more comprehensive (like
> > > ability to ptrace) would be appropriate.
> >
> > I would go a lot simpler. App says "I want exclusivity" via pctl and
> > NOTHING runs on the other half. Well maybe with exceptions of
> > processes that share the mm with the exclusive one (in practice
> > "threads") since those could just read the memory anyway.
>
> this has the disadvantage of needing changes in the security apps.
> Basing this off the uid (or the ability to ptrace) makes it at least
> automatic - but introduces a permanent penalty not only on multiuser
> boxes, but on basically any server box that runs multiple services.

The performance penalty of the sample patch without extra communication or 
code would be substantial and I should make it clear to any onlookers that it 
is not recommended you use it in any real environment.

Cheers,
Con

Re: [PATCH] Sample fix for hyperthread exploit

[Amit Shah]

Ingo Molnar wrote:

> 
> * Arjan van de Ven <arjan@infradead.org> wrote:
> 
>> > Also, uid is not sufficient.  Something more comprehensive (like
>> > ability to ptrace) would be appropriate.
>> 
>> I would go a lot simpler. App says "I want exclusivity" via pctl and
>> NOTHING runs on the other half. Well maybe with exceptions of
>> processes that share the mm with the exclusive one (in practice
>> "threads") since those could just read the memory anyway.
> 
> this has the disadvantage of needing changes in the security apps.
> Basing this off the uid (or the ability to ptrace) makes it at least
> automatic - but introduces a permanent penalty not only on multiuser
> boxes, but on basically any server box that runs multiple services.

Can this be not limited to just not running any other process on the same
(SMT-enabled) processor (precondition being ability to ptrace)?

Amit.
-- 
Amit Shah
http://amitshah.net/