All of lore.kernel.org
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave@stgolabs.net>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	akpm@linux-foundation.org
Subject: Re: Smatch check for Spectre stuff
Date: Mon, 23 Apr 2018 10:11:31 -0700	[thread overview]
Message-ID: <20180423171131.njs4rfm2yzyeg6do@linux-n805> (raw)
In-Reply-To: <20180419051510.GA21898@mwanda>

So both smatch and coverity are complaining about sysvipc sems.
They look legit (if the policy is, as peterz describes: "kill
any speculation on the first load and not worry if it can be
completed with a dependent load/store").

On Thu, 19 Apr 2018, Dan Carpenter wrote:
>ipc/sem.c:1359 semctl_setval() warn: potential spectre issue 'sma->sems' (local cap)
>ipc/sem.c:1512 semctl_main() warn: potential spectre issue 'sma->sems' (local cap)


And for this one the below patch already sanitizes semnum to be between
[0, sma->sem_nsems) before calling into count_semcnt().

>ipc/sem.c:1096 count_semcnt() warn: potential spectre issue 'sma->sems'
>ipc/sem.c:2084 do_semtimedop() warn: potential spectre issue 'sma->sems'
>ipc/sem.c:388 sem_lock() warn: potential spectre issue 'sma->sems'
>ipc/sem.c:641 perform_atomic_semop_slow() warn: potential spectre issue 'sma->sems'
>ipc/sem.c:721 perform_atomic_semop() warn: potential spectre issue 'sma->sems'

Thanks,
Davidlohr

----8<--------------------------------------------------
[PATCH] sysvipc/sem: mitigate semnum index against spectre v1.

Both smatch and coverity are reporting potential issues
with spectre variant 1 with the 'semnum' index within the
sma->sems array, ie:

ipc/sem.c:388 sem_lock() warn: potential spectre issue 'sma->sems'
ipc/sem.c:641 perform_atomic_semop_slow() warn: potential spectre issue 'sma->sems'
ipc/sem.c:721 perform_atomic_semop() warn: potential spectre issue 'sma->sems'

Avoid any possible speculation by using array_index_nospec() thus
ensuring the semnum value is bounded to [0, sma->sem_nsems). With
the exception of sem_lock() all of these are slowpaths.

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---

 ipc/sem.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index 06be75d9217a..df623dcefc92 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -84,6 +84,7 @@
 #include <linux/nsproxy.h>
 #include <linux/ipc_namespace.h>
 #include <linux/sched/wake_q.h>
+#include <linux/nospec.h>
 
 #include <linux/uaccess.h>
 #include "util.h"
@@ -367,6 +368,7 @@ static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
 			      int nsops)
 {
 	struct sem *sem;
+	int idx;
 
 	if (nsops != 1) {
 		/* Complex operation - acquire a full lock */
@@ -384,7 +386,8 @@ static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
 	 *
 	 * Both facts are tracked by use_global_mode.
 	 */
-	sem = &sma->sems[sops->sem_num];
+	idx = array_index_nospec(sops->sem_num, sma->sem_nsems);
+	sem = &sma->sems[idx];
 
 	/*
 	 * Initial check for use_global_lock. Just an optimization,
@@ -637,7 +640,8 @@ static int perform_atomic_semop_slow(struct sem_array *sma, struct sem_queue *q)
 	un = q->undo;
 
 	for (sop = sops; sop < sops + nsops; sop++) {
-		curr = &sma->sems[sop->sem_num];
+		int idx = array_index_nospec(sop->sem_num, sma->sem_nsems);
+		curr = &sma->sems[idx];
 		sem_op = sop->sem_op;
 		result = curr->semval;
 
@@ -717,7 +721,9 @@ static int perform_atomic_semop(struct sem_array *sma, struct sem_queue *q)
 	 * until the operations can go through.
 	 */
 	for (sop = sops; sop < sops + nsops; sop++) {
-		curr = &sma->sems[sop->sem_num];
+		int idx = array_index_nospec(sop->sem_num, sma->sem_nsems);
+
+		curr = &sma->sems[idx];
 		sem_op = sop->sem_op;
 		result = curr->semval;
 
@@ -1349,6 +1355,7 @@ static int semctl_setval(struct ipc_namespace *ns, int semid, int semnum,
 		return -EIDRM;
 	}
 
+	semnum = array_index_nospec(semnum, sma->sem_nsems);
 	curr = &sma->sems[semnum];
 
 	ipc_assert_locked_object(&sma->sem_perm);
@@ -1502,6 +1509,8 @@ static int semctl_main(struct ipc_namespace *ns, int semid, int semnum,
 		err = -EIDRM;
 		goto out_unlock;
 	}
+
+	semnum = array_index_nospec(semnum, nsems);
 	curr = &sma->sems[semnum];
 
 	switch (cmd) {
@@ -2072,7 +2081,8 @@ static long do_semtimedop(int semid, struct sembuf __user *tsops,
 	 */
 	if (nsops == 1) {
 		struct sem *curr;
-		curr = &sma->sems[sops->sem_num];
+		int idx = array_index_nospec(sops->sem_num, sma->sem_nsems);
+		curr = &sma->sems[idx];
 
 		if (alter) {
 			if (sma->complex_count) {
-- 
2.13.6

  parent reply	other threads:[~2018-04-23 17:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19  5:15 Smatch check for Spectre stuff Dan Carpenter
2018-04-19 21:39 ` Gustavo A. R. Silva
2018-04-20 12:00 ` Peter Zijlstra
2018-04-23 12:31   ` Gustavo A. R. Silva
2018-04-23 12:45     ` Peter Zijlstra
2018-04-23 13:08       ` Gustavo A. R. Silva
2018-04-23 13:48       ` Dan Williams
2018-04-20 12:25 ` Thomas Gleixner
2018-04-20 17:21   ` Oleg Nesterov
2018-04-20 12:47 ` Mark Rutland
2018-04-23 12:53   ` Dan Carpenter
2018-04-23 13:22     ` Mark Rutland
2018-04-23 13:26       ` Dan Carpenter
2018-04-23 17:11 ` Davidlohr Bueso [this message]
2018-04-25 13:19 ` Mark Rutland
2018-04-25 14:48   ` Alan Cox
2018-04-25 15:03     ` Mark Rutland
2018-06-08 16:12 ` Josh Poimboeuf
2018-06-11  9:28   ` Peter Zijlstra
2018-06-13 13:10   ` Dan Carpenter
2018-06-13 13:58     ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180423171131.njs4rfm2yzyeg6do@linux-n805 \
    --to=dave@stgolabs.net \
    --cc=akpm@linux-foundation.org \
    --cc=dan.carpenter@oracle.com \
    --cc=gustavo@embeddedor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.