Received: by 10.223.176.46 with SMTP id f43csp1351213wra; Fri, 19 Jan 2018 10:13:39 -0800 (PST) X-Google-Smtp-Source: ACJfBovtAhYDocHYlyzKmZarDYykP5xBfH3RabUM/W1yQKY8bOAu8XO6n7LX4NGdD0mpblJZTkpn X-Received: by 10.99.168.76 with SMTP id i12mr20677539pgp.119.1516385619733; Fri, 19 Jan 2018 10:13:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516385619; cv=none; d=google.com; s=arc-20160816; b=C+Gyl3yE1nMHvBQd3OnQvNxwLWOW3muXss+tVm1PU+ThtKRbpXGyUQzMBdcp0Ld1PU K3xfmYO74Sf+h/0v5Vsqcot31eMb3hb+uGYkswqnW7e/+UsHkRauBsnAx1+xSEQt8Zyh ZlsoZtnGNUIfOmaLxR+t5slncIeOEXPLoZi2/GYNVkUlwHd14atp9AIC26Lf8kvxpZPu t98MiFXstOWPepEi0fBH1VEw7NIgBQ3Hb2WsAnLkQyllEvPGB9l4B4x5RgO7YLhBL292 9zPhAB7T2T0QwCqlaYCMDcSjLwKzWCt0hX4EmpRb2FpiifY3KdhN3RgrZaagjnJePy/I +REQ== 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=ui19pjar2t9yG30bRBJ81GGKAq2n3hydZSL9/w4fDSo=; b=xz13i5LYPP1dJ+Kx9npRZ4OcW/hJx+3JNLr1jkI+1okKRcVSNHGkv26ZepWcQS/K35 CpZBT3auyYfFOLbzIe4VjXfmRCZEReG6Dmhg5U1BXWdrN/tj8L+b36ZCgBONnR/qsagd bvK5tY9qFfTllJfw2v/dRL/sM9en5VjGyBBo1v9FNrAmZSgfyXiQmKBOuWXLmPzhlbTa HCAqLqaBmj/uoN+tCDC8uXXsiMOXPqJ4/6i5/hk0IPL1oT+yVc4SdyD3FN4JgLnLkplw +ef3BPxu8J2j8mNubu6T03MNImCoK5qXIqGYkD3YVaQR2sQEH3qPRULNR4Ghqn4fM4yI VoyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=gOZFDgUa; 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 a89si9760661pfj.107.2018.01.19.10.13.25; Fri, 19 Jan 2018 10:13:39 -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=gOZFDgUa; 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 S1756040AbeASSMz (ORCPT + 99 others); Fri, 19 Jan 2018 13:12:55 -0500 Received: from mail-ot0-f196.google.com ([74.125.82.196]:42575 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755981AbeASSMs (ORCPT ); Fri, 19 Jan 2018 13:12:48 -0500 Received: by mail-ot0-f196.google.com with SMTP id s3so2128011otc.9 for ; Fri, 19 Jan 2018 10:12:48 -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=ui19pjar2t9yG30bRBJ81GGKAq2n3hydZSL9/w4fDSo=; b=gOZFDgUaLIXL0xDHqsJIxm7qriZpMjN2CxoiSi6Rj3WZUQcvPlwxG9sPP0ZPHzFT4e bBSymtUOV5ZWvR7ArwftqGT5apHvCVbPjtdXNqZYmLT5KRMMOhFL3NIByMgKreCj/jwW 9ue9D5czLfidiy8F1rR6iG7yVIwiUwIhWnluR6V1Fa7CRv8KH++Ye0kLat6srRnuc2+5 dG/RwDFUFmlBV7wcQrTB+FEuvy+O9uirL8o7j3wFSAyKbiq+67SOg6e4kUkFNZ5KJNVQ gyxyDiQHFzlY8fbej9QDDH8uCKLwM6nBTK7NaL2piHcvBxCLZruvhOSkkMQ8HcX1hNTu QBEQ== 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=ui19pjar2t9yG30bRBJ81GGKAq2n3hydZSL9/w4fDSo=; b=OVYhAI1BNZr18ocODqa/RsKvoHcqbkhW2G1vXLSxvZne4mw0JAh1V6ytAPMivUu5w2 HD+Kj0M3QXmv76d6dIluMXnPvHqqHz/cjiUEbktjYke7xj0hhEVzRqjOMkAuk/5Iww9W 5kPjar49RLSyV4wvujJSEllc6zs2oWXv5HyzJ5rsPyuudFQrwzNPekmEb5TDh2wzbdoq jwfEnxgtc7uKWEjDb0pr/1dcdvXNe/KqOOwGLdCw+mR+v0/rpug19eOTH8QW8BuzbhZU rquQt2Y3lFtekn8P4KcfoK3+nG3dO6TUKCtcFEQtYpMgEFuW1ez5m0secIv+h0uuPpq5 HRGA== X-Gm-Message-State: AKwxyterrZVj9tnIhrUPLYF/+oosNygUCL7CPiypBIVyVDQiKenSjUsh k3gB9waf+8FNAJVF1lvtcZ9YHUMtyAW56vRXUzvyJg== X-Received: by 10.157.0.102 with SMTP id 93mr5887290ota.175.1516385567608; Fri, 19 Jan 2018 10:12:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.62.72 with HTTP; Fri, 19 Jan 2018 10:12:47 -0800 (PST) In-Reply-To: References: <151632009605.21271.11304291057104672116.stgit@dwillia2-desk3.amr.corp.intel.com> <151632010687.21271.12004432287640499992.stgit@dwillia2-desk3.amr.corp.intel.com> From: Dan Williams Date: Fri, 19 Jan 2018 10:12:47 -0800 Message-ID: Subject: Re: [kernel-hardening] [PATCH v4 02/10] asm/nospec, array_ptr: sanitize speculative array de-references To: Adam Sampson Cc: Jann Horn , kernel list , linux-arch , Kernel Hardening , Catalin Marinas , "the arch/x86 maintainers" , Will Deacon , Russell King , Ingo Molnar , Greg Kroah-Hartman , "H. Peter Anvin" , Thomas Gleixner , Linus Torvalds , Andrew Morton , Alan Cox , Alexei Starovoitov 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 [ adding Alexei back to the cc ] On Fri, Jan 19, 2018 at 9:48 AM, Adam Sampson wrote: > Jann Horn writes: > >>> +/* >>> + * If idx is negative or if idx > size then bit 63 is set in the mask, >>> + * and the value of ~(-1L) is zero. When the mask is zero, bounds check >>> + * failed, array_ptr will return NULL. >>> + */ >>> +#ifndef array_ptr_mask >>> +static inline unsigned long array_ptr_mask(unsigned long idx, >>> unsigned long sz) >>> +{ >>> + return ~(long)(idx | (sz - 1 - idx)) >> (BITS_PER_LONG - 1); >>> +} >>> +#endif >> >> Nit: Maybe add a comment saying that this is equivalent to >> "return ((long)idx >= 0 && idx < sz) ? ULONG_MAX : 0"? > > That's only true when sz < LONG_MAX, which is documented below but not > here; it's also different from the asm version, which doesn't do the idx > <= LONG_MAX check. So making the constraint explicit would be a good idea. > > From a bit of experimentation, when the top bit of sz is set, this > expression, the C version and the assembler version all have different > behaviour. For example, with 32-bit unsigned long: > > index=00000000 size=80000001: expr=ffffffff c=00000000 asm=ffffffff > index=80000000 size=80000001: expr=00000000 c=00000000 asm=ffffffff > index=00000000 size=a0000000: expr=ffffffff c=00000000 asm=ffffffff > index=00000001 size=a0000000: expr=ffffffff c=00000000 asm=ffffffff > index=fffffffe size=ffffffff: expr=00000000 c=00000000 asm=ffffffff > > It may be worth noting that: > > return 0 - ((long) (idx < sz)); > > causes GCC, on ia32 and amd64, to generate exactly the same cmp/sbb > sequence as in Linus's asm. Are there architectures where this form > would allow speculation? We're operating on the assumption that compilers will not try to introduce branches where they don't exist in the code, so if this is producing identical assembly I think we should go with it and drop the x86 array_ptr_mask.