Received: by 10.192.165.148 with SMTP id m20csp3679965imm; Mon, 23 Apr 2018 10:27:06 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+jbY0DbZJtbt2aF9wCEXQ/soZwbS1WCU1Sor2e5Hw/rIkzsuF/Yk1mNORiWDpdBmbjwJvZ X-Received: by 2002:a17:902:6d0f:: with SMTP id s15-v6mr21493540plk.241.1524504426156; Mon, 23 Apr 2018 10:27:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524504426; cv=none; d=google.com; s=arc-20160816; b=iuU7NsKdPSWdY9U9dRBYfXTVJnHKcPi0h75+TWngXmyXrm4Gzvj0aktJGLYUBNNI1m Tk6GR+jx1F9sG3tl/9lIlf9p0wu+cGxplpWT0vzGrTRUuzx+ELIYnIO2LdWpx8lYwStm s2qnqLNO78l6X3vTYMo6MKQfpJoEtcNLjLZPzmx1W9DOYyNm4zq2UZAdZvlzWWV/dzci ing7eImnxDnzRTKEt5mdeN1yGItumK/77wpLKt875+9LPEYujHmsjc5yX10SbCSpDASR YyrlcvSD+IW7xQhTNxZLNDp6BoL6PW3U2ZJ3X67qDXMI4NZmobFhOkFcm/W1FW0XZkC4 gJdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=OBgo6KW9EdoUgvGTWJwPCfWAY1UB6xOh6HyvNCwPcUo=; b=FxJvrGGoRZiuLWMW7ndb2p0ojKl/9B77Cj0sS6o2tRLk7jLv8NZ8S/pf5iB4qh/HTz bOetwtBSu6+ndZAD7XH534t850Lcj7FMWAurS8d1o8wItNqGimAjiwXDzI+4gmb2Pn8W op11+KpmHB0JFvlPvq6Kvm+lwMRk/mNoHrtTudepiGwFZVA67vMIpelRdMyhnsUiiDJq NnugjJ/qvk0hrc3F3HL2mFwYMrnzf0zv6Vltzit0fyTITFXEmu4o9Xr/z2eFyrwv4Ber EtakZWpFig/BaMBTf19G0ZBUuKpiQHA6lroL9GSNVxuTQ9RmGgCuSWN+2Lz6xITozh0y CM/g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n136si4931662pfd.312.2018.04.23.10.26.51; Mon, 23 Apr 2018 10:27:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932144AbeDWRZv (ORCPT + 99 others); Mon, 23 Apr 2018 13:25:51 -0400 Received: from mx2.suse.de ([195.135.220.15]:33719 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932076AbeDWRZu (ORCPT ); Mon, 23 Apr 2018 13:25:50 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AC99CAED1; Mon, 23 Apr 2018 17:25:48 +0000 (UTC) Date: Mon, 23 Apr 2018 10:11:31 -0700 From: Davidlohr Bueso To: Dan Carpenter Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , "Gustavo A. R. Silva" , akpm@linux-foundation.org Subject: Re: Smatch check for Spectre stuff Message-ID: <20180423171131.njs4rfm2yzyeg6do@linux-n805> References: <20180419051510.GA21898@mwanda> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20180419051510.GA21898@mwanda> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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 #include #include +#include #include #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