Sample fix for hyperthread exploit
PATCH 1/1 Sample fix for hyperthread exploit
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?
kernel/sched.c +15 -0
@@ -2530,6 +2530,21 @@ static inline int dependent_sleeper(inttask_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
Quoted 2 lines
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.
Quoted 6 lines · Arjan van de Ven
Quoted 1 line
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
Quoted 11 lines · * Con Kolivas ([email protected]) wrote:
Quoted 6 lines · Arjan van de Ven
Quoted 1 line
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
Quoted 9 lines · Chris Wright
Quoted 8 lines · * Con Kolivas ([email protected]) wrote:
Quoted 6 lines · Arjan van de Ven
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines · Arjan van de Ven
Quoted 2 lines
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
Quoted 9 lines · Ingo Molnar
Quoted 7 lines · Arjan van de Ven
Quoted 2 lines
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.
Quoted 4 lines
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
Quoted 11 lines · Ingo Molnar
Quoted 7 lines · Arjan van de Ven
Quoted 2 lines
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.
Quoted 4 lines
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.
Signature · 2 lines
Amit Shah http://amitshah.net/