Received: by 10.223.185.116 with SMTP id b49csp2111812wrg; Thu, 15 Feb 2018 06:47:17 -0800 (PST) X-Google-Smtp-Source: AH8x226xgbXt2HGTDN33L/FZOEXz/GgS3nvbTM/2oH5ovifJxGJ1Yu+7BItLCirmY8+72riOML86 X-Received: by 10.99.4.66 with SMTP id 63mr2399007pge.93.1518706037204; Thu, 15 Feb 2018 06:47:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518706037; cv=none; d=google.com; s=arc-20160816; b=I+VVbU6NbawnTUKQtCpVeQ8JkKm0Q46SOhCJkroHoX+39IQJY5ym1umrD5U8j0Wfrg f1Wg3WuUKFtn1eoSPNaSBoys3CXsQ+6gBVBVvtBXpoPjCvxOzqmZurrPbyF7gKlht/25 nomvS5u5Q+EU44aeuIrcjr+coab4YCIKBS4DQttlq4fHUN35MGtQPabR33vSbdCbN73V +ZvSkP/oyCUgy5SQTx4FUXE7YTiV3Sy0uZFyCMSfUnR+IoH+eRTsjfOIUHcqweCILfri 2mhZpK//dmsCsb8UnHa9KJ/EpMhZcge/CWSTQecvlBZ2/QvGyHN/uuIcr9PTzYYu1FiX DQoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=VIN0lqIF8D0HC+3oORSavC1GNSgPZkQ5GYacyHGYcdA=; b=dPEcAWifUamDbEeWODu7i95mMM6Z2cJIdvB0xwddVFpuiD1Dr1uD1ikvljwKFYbis2 ZlBsfzsjhFEiy5XJMqsbx8QECqHe3OHlKI4wWw/arsHKglOHkIqHeOG+dBPYwB2D344I jvib//GmHxlwflEmw9kf3WlbrCamE1fdPgrGfMhW2gJM+5oEA79GA+w41kuROPDtXaHq dCTh3+v7QEAHJBiIxav7Hxx2iV89xTg/j6LMOv0bsHRf6LMB3g7q11EkNOyfsYtiXDiE RW4mRXE4eQyn43OJo/UbPphLA4bBcGRTyTrc140aE6PlO6TGY1MCkNDHRwwMUT7W0BfG uROw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=CBQjQINo; 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 f84si2868901pfh.363.2018.02.15.06.47.02; Thu, 15 Feb 2018 06:47:17 -0800 (PST) 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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=CBQjQINo; 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 S1033428AbeBOOjP (ORCPT + 99 others); Thu, 15 Feb 2018 09:39:15 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:41353 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033381AbeBOOjO (ORCPT ); Thu, 15 Feb 2018 09:39:14 -0500 Received: by mail-oi0-f66.google.com with SMTP id t145so1373070oif.8 for ; Thu, 15 Feb 2018 06:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VIN0lqIF8D0HC+3oORSavC1GNSgPZkQ5GYacyHGYcdA=; b=CBQjQINojt1OmMaxizHZtrrj92772i5KVvwR5MMyfwMDQ4f63ZWV7F9tiBU+v37Jce 4eCCeeascA9qGStFYJxnjfB2bMfG0QzMbPIiLRNOHjHtGQwMvQJbyJKl2TWBdxJzEru1 Fl4LEltjYpEQjJ2xQ/fVZ0Mi+bUq45GwMe7etmsdZObcsTjsO04pgw0kOeuyzeIUHx7R G4tW3BCTFFW+CrGMxkQCFkCq2NsO2T2V/yynVNHhLOagk+zOLfEam7MPFwV2aJseM757 ANOn/mRIpTTlykaOMeKBLDBa6NFEO2+SA0PfBdvptxSq8NQ3J14/ClOnK107KHZ2Ahb5 KOSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VIN0lqIF8D0HC+3oORSavC1GNSgPZkQ5GYacyHGYcdA=; b=qV0cXuEgnMVfPGQTzL1kMPbfoWLF7NKRNwNFqe/87WuKiFVwH1fTb2Ro3sSgWiMESQ eePhxGm+0wDXay48TRi/eNLZu/ExlzP6lnoKE/sevh5Uzbkk60EOg+KNaOZd1KAnjJWE 6Zi5iSsdJYb77YmW4b/UoyR3t35vQMlYeKs/2URFP5Hs8tm9tYOVhFlgU6iQXzrKG91A xqao1N7A1DzW8LAmdp4I6ZFYFGo+poCN3xq8mYy9B+ileEl7nr0+iDqyxSd4+PMjNqqE 9NNRbWOTuSw4FNSOJ4CvDgb3g0yYYlUHnrRLMHs4TNdyASCY7+kGK3U9Vp9TdnWuajmO YT7A== X-Gm-Message-State: APf1xPCicGRB6NG5nruifJW4WzC0bToPf4pLX00IR2kDO9V2DAG505EZ vmYv2zgfQKiRaApT0+AorPqzO0z3WvSgct3yR0vepg== X-Received: by 10.202.222.139 with SMTP id v133mr2027701oig.298.1518705553914; Thu, 15 Feb 2018 06:39:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.17.229 with HTTP; Thu, 15 Feb 2018 06:39:13 -0800 (PST) In-Reply-To: <45f8dece-e235-0831-4fe5-89ee7d27b959@prevas.dk> References: <45f8dece-e235-0831-4fe5-89ee7d27b959@prevas.dk> From: Dan Williams Date: Thu, 15 Feb 2018 06:39:13 -0800 Message-ID: Subject: Re: [PATCH] posix-timers: Protect posix clock array access against speculation To: Rasmus Villemoes Cc: Thomas Gleixner , LKML , Ingo Molnar , Linus Torvalds , David Woodhouse , Greg KH Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 15, 2018 at 6:05 AM, Rasmus Villemoes wrote: > On 2018-02-15 14:27, Thomas Gleixner wrote: >> The (clock) id argument of clockid_to_kclock() comes straight from user >> space via various syscalls and is used as index into the posix_clocks >> array. >> >> Protect it against spectre v1 array out of bounds speculation. >> >> Signed-off-by: Thomas Gleixner >> Cc: stable@vger.kernel.org >> --- >> kernel/time/posix-timers.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> --- a/kernel/time/posix-timers.c >> +++ b/kernel/time/posix-timers.c >> @@ -50,6 +50,7 @@ >> #include >> #include >> #include >> +#include >> >> #include "timekeeping.h" >> #include "posix-timers.h" >> @@ -1346,11 +1347,14 @@ static const struct k_clock * const posi >> >> static const struct k_clock *clockid_to_kclock(const clockid_t id) >> { >> + clockid_t idx = id; >> + >> if (id < 0) >> return (id & CLOCKFD_MASK) == CLOCKFD ? >> &clock_posix_dynamic : &clock_posix_cpu; >> >> if (id >= ARRAY_SIZE(posix_clocks) || !posix_clocks[id]) >> return NULL; >> - return posix_clocks[id]; >> + >> + return posix_clocks[array_index_nospec(idx, ARRAY_SIZE(posix_clocks))]; >> } >> > > Stupid questions from someone trying to learn what the rules for when > and how to apply these _nospec macros: > > (1) why introduce the idx var? There's no assignment to it other than > the initialization. Is it some magic in array_index_nospec that prevents > the use of a const-qualified expression? It does currently, but perhaps it can be fixed. > > (2) The line "if (id >= ARRAY_SIZE(posix_clocks) || !posix_clocks[id])" > still seems to allow speculatively accessing posix_clocks[id]. Is that > ok, and even if so, wouldn't it be cleaner to elide the > !posix_clocks[id] check and just return the NULL safely fetched from the > array in the following line? Right, this looks broken. I would expect: if (id >= ARRAY_SIZE(posix_clocks)) return NULL; idx = array_index_nospec(idx, ARRAY_SIZE(posix_clocks)); if (!posix_clocks[idx]) return NULL; return posix_clocks[idx];