From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1516385934; cv=none; d=google.com; s=arc-20160816; b=wPCsSvdSdcySc12Gj13SX46BtbnV/jLnDiqtM9s2LlIyT2zAZBWjxHZh5y3Rc++XzJ 9LsSE70UwfREBOEK2uVKFL+kDsDtYBntNwaXKKfhqiAQMesGae7OP2zoy2Q90NB/moo2 476hvjbg1ZeIxzODF7WfcTdqLvSYh02KTEe9m9l87u5D+qHVBADScN6DLXQKAQNujhaT uIIj2QOlDP9q1nHeuoYEfCAV6s6L7PNgMDtGoCTlVo8MD7puI9/yGCiEPS1axkTEcsur Gpzj7DB/WpAaCJJvhqkZSIGQrP07peseREj7Ktm2iYj+QsYiqwHXuWmttNP19RGEGxLG dzhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to:sender :mime-version:dkim-signature:arc-authentication-results; bh=1vR6y0d8hO8KKMwqH6k5h27jo0VPbbHrTF7fuBowPW0=; b=s/k5j6hriStFf+PTKq0HyxW5VxIWFAmufUBuA8t8YY0W3YgZHhcOyOpsnVdWH56Ar6 J1ZOKTtx4Jl12oNwhXDft726sjQW/BOy4mBbsLdbCt8LXZY0z4IZYrZdo5e3XL9TZaYY KHXrvSQQRNBYuwdY/EY3zBxCEYSu17v6OCW14O0n/ClBDpR3QWmGvoYybXR7d7dk5vqV XdkWwF52p0bj5xVXrvYNeLMUAKVUFY6IJT6FsEwwmHW2NJLrWEbKUrKUK+qMPyNFT5tI zKY4e/Iu0XlTooJu1JeMrpd7YheTi1rrxI6rA9CcicBTv+BNbD7G/f4Huz+5TplhcDRH h2vA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uyLDAlXF; spf=pass (google.com: domain of linus971@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=linus971@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uyLDAlXF; spf=pass (google.com: domain of linus971@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=linus971@gmail.com X-Google-Smtp-Source: AH8x227T+ritc+jshW2yYHnCD71z4skgCABTLSR1p5gTP8ljtmUkj6t7N9GqO6VOd1wHsKiHRlxpKYiKWHx7+77ts9A= MIME-Version: 1.0 Sender: linus971@gmail.com 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: Linus Torvalds Date: Fri, 19 Jan 2018 10:18:53 -0800 X-Google-Sender-Auth: bX8kYGhHZl0wrEYJtSV2X2BDBhk Message-ID: Subject: Re: [kernel-hardening] [PATCH v4 02/10] asm/nospec, array_ptr: sanitize speculative array de-references To: Jann Horn Cc: Dan Williams , 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 , Andrew Morton , Alan Cox Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589977446378237360?= X-GMAIL-MSGID: =?utf-8?q?1590045897668808228?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Fri, Jan 19, 2018 at 2:20 AM, Jann Horn wrote: >> + \ >> + __u._ptr = _arr + (_i & _mask); \ >> + __u._bit &= _mask; \ > > AFAICS, if `idx` is out of bounds, you first zero out the index > (`_i & _mask`) and then immediately afterwards zero out > the whole pointer (`_u._bit &= _mask`). > Is there a reason for the `_i & _mask`, and if so, can you > add a comment explaining that? I think that's just leftovers from my original (untested) thing that also did the access itself. So that __u._bit masking wasn't masking the pointer, it was masking the value that was *read* from the pointer, so that you could know that an invalid access returned 0/NULL, not just the first value in the array. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH v4 02/10] asm/nospec, array_ptr: sanitize speculative array de-references Date: Fri, 19 Jan 2018 10:18:53 -0800 Message-ID: References: <151632009605.21271.11304291057104672116.stgit@dwillia2-desk3.amr.corp.intel.com> <151632010687.21271.12004432287640499992.stgit@dwillia2-desk3.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Sender: linus971@gmail.com In-Reply-To: To: Jann Horn Cc: Dan Williams , 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 , Andrew Morton , Alan Cox List-Id: linux-arch.vger.kernel.org On Fri, Jan 19, 2018 at 2:20 AM, Jann Horn wrote: >> + \ >> + __u._ptr = _arr + (_i & _mask); \ >> + __u._bit &= _mask; \ > > AFAICS, if `idx` is out of bounds, you first zero out the index > (`_i & _mask`) and then immediately afterwards zero out > the whole pointer (`_u._bit &= _mask`). > Is there a reason for the `_i & _mask`, and if so, can you > add a comment explaining that? I think that's just leftovers from my original (untested) thing that also did the access itself. So that __u._bit masking wasn't masking the pointer, it was masking the value that was *read* from the pointer, so that you could know that an invalid access returned 0/NULL, not just the first value in the array. Linus