Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2926454yba; Mon, 6 May 2019 13:59:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqwQ3bHtiVs7Av7biTpdOwnzNO24GvY3OxMPLBgG6RS+d+KNhh8noibEw9QvNuxJn9uEjlkS X-Received: by 2002:a65:49c7:: with SMTP id t7mr11458928pgs.324.1557176362473; Mon, 06 May 2019 13:59:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557176362; cv=none; d=google.com; s=arc-20160816; b=OTxSaWg5BvyqGtfvWv81kfr0p91UuExTfecqME6ljy5asvexR6Tu2NBk6GR783pgT+ zXmVRExcGwSzJUr/CcrwGCWXXw3u15YLHvOo6IHCAMBDLTu979GD3lwU+d8eGFgDTabp kNkLV68ni2Ydo66Sdh2lbE0ra9Pw5X1Gi4SMQqIPLEBcOh+lq0oqMhkbv+7i4/0d7Koh f+WWMR1aNVJCvzzn9lqI9brS8ZZeWATe7aqBZQtHM5IA5j8PyUBTmeTZV2UiCmc5Dsbi NYYNejbVUQUOsuRdbpWYRsc1UqrpihS6obpbV8mqHTXAuklob+XsFxE5WxQJ+yg4+Jbw ekBQ== 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:dkim-signature; bh=kLvBEkbGH2riUHwBmQ3jNmUgnYR588n2GWNQ8y8PGCE=; b=Ib/sL2TExfIs4NLIULYeh9yCSp85ioSOXTUv5g48P373NUGaetUKXyVb6drX6Ymjvz IfQnSks3hXfERpYRd6jrf/Kkv12L0kaYRlfPAd/6fEd5BFw/Cdfxl01AGJfjx4HDpDtA F/ECISMPYSi9M1TEk0Ug7RxGDy5GEfJJM9VeOsdkyICnDPBMHYqJqTMLASY2p7b92WmC NUPrEsvvJvhv95g2SoXTKCJirGy5CYXO+ylAKw4jzAP6SQcgYMe0BP1bF5OoSFz8HP4z d5ZyOes3Q+qS2s2LU8smojek2kNzSMXX/t8FcvfwvQDa03fZ+LWgpksAKCuWfNCaLy1z 5wLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=OTEKU73c; 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 31si17866379plk.42.2019.05.06.13.59.06; Mon, 06 May 2019 13:59:22 -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; dkim=pass header.i=@joelfernandes.org header.s=google header.b=OTEKU73c; 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 S1726457AbfEFU6M (ORCPT + 99 others); Mon, 6 May 2019 16:58:12 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:33443 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726282AbfEFU6L (ORCPT ); Mon, 6 May 2019 16:58:11 -0400 Received: by mail-pf1-f196.google.com with SMTP id z28so7411153pfk.0 for ; Mon, 06 May 2019 13:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kLvBEkbGH2riUHwBmQ3jNmUgnYR588n2GWNQ8y8PGCE=; b=OTEKU73clE6B6zjUJhEw6aF1TCgyEE6l6Jlty1yHWx43iZ9pTMHpSlvBIvsXC3DZqW 3dRE5Jt67zdSEBTCnNkF2c1i/hWhxPopBmGZWoN285CLByjeps7LkIuNvBSgYnPbwJlA IFqm8+81yGkeBshC/6R5YWtE7k47BPcG7nsxg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kLvBEkbGH2riUHwBmQ3jNmUgnYR588n2GWNQ8y8PGCE=; b=BrfvX+lllR5lb0NpvqW+5no2Q1sRbrpiE0699IdvW1Ii9BSx4ShmjEao8s+dOjSEzZ eOkwZDtyNhWjd+73IV47O6OfhGZgLjUvfZBNNl/nO+Nplvi8STc+G/M7wW2sUIhhW+Tq S5Nsq9J7Wq9Fa6063rylH4WkvtHi4IixGYuTtM7Fm716W5RXCfZZ8LIdUm/eFBLZJW9p Bfs0chE9NKruOKAY43Rhaa0H9+bkCDFFl9OhyP5IadF3xCYHeJ51+XlT9mOC3YPIYZzK 9JvbIZxT6IhffixOrVI0rnxWrsAjTs9tNHVqktDUh5parU3NNJ2IwUG+DJXQ2rdexBWp pHuQ== X-Gm-Message-State: APjAAAWq+oudjtv5VFje/qkSKAslQsVvBUz8b2xjTTyazU/VUpcDec9H I8Y5qurwfu3JGFAuNEV6niYZOQ== X-Received: by 2002:aa7:8384:: with SMTP id u4mr35598358pfm.214.1557176289853; Mon, 06 May 2019 13:58:09 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id l23sm5007490pgh.68.2019.05.06.13.58.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 May 2019 13:58:08 -0700 (PDT) Date: Mon, 6 May 2019 16:58:07 -0400 From: Joel Fernandes To: Will Deacon Cc: Qais Yousef , linux-kernel@vger.kernel.org, Michal Gregorczyk , Adrian Ratiu , Mohammad Husain , Srinivas Ramana , duyuchao , Manjo Raja Rao , Karim Yaghmour , Tamir Carmeli , Yonghong Song , Alexei Starovoitov , Brendan Gregg , Masami Hiramatsu , Peter Ziljstra , Steven Rostedt , Kees Cook , kernel-team@android.com, Daniel Borkmann , Ingo Molnar , netdev@vger.kernel.org, Mark Rutland Subject: Re: [PATCH RFC] bpf: Add support for reading user pointers Message-ID: <20190506205807.GA223956@google.com> References: <20190502204958.7868-1-joel@joelfernandes.org> <20190503121234.6don256zuvfjtdg6@e107158-lin.cambridge.arm.com> <20190503134935.GA253329@google.com> <20190505110423.u7g3f2viovvgzbtn@e107158-lin.cambridge.arm.com> <20190505132949.GB3076@localhost> <20190505144608.u3vsxyz5huveuskx@e107158-lin.cambridge.arm.com> <20190505155223.GA4976@localhost> <20190505180313.GA80924@google.com> <20190506183506.GD2875@brain-police> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190506183506.GD2875@brain-police> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 06, 2019 at 07:35:06PM +0100, Will Deacon wrote: > Hi Joel, > > On Sun, May 05, 2019 at 02:03:13PM -0400, Joel Fernandes wrote: > > +Mark, Will since discussion is about arm64 arch code. > > > > The difference between observing the bug and everything just working seems to > > be the set_fs(USER_DS) as done by Masami's patch that this patch is based on. > > The following diff shows 'ret' as 255 when set_fs(KERN_DS) is used, and then > > after we retry with set_fs(USER_DS), the read succeeds. > > > > diff --git a/mm/maccess.c b/mm/maccess.c > > index 78f9274dd49d..d3e01a33c712 100644 > > --- a/mm/maccess.c > > +++ b/mm/maccess.c > > @@ -32,9 +32,20 @@ long __probe_kernel_read(void *dst, const void *src, size_t size) > > pagefault_disable(); > > ret = __copy_from_user_inatomic(dst, > > (__force const void __user *)src, size); > > + trace_printk("KERNEL_DS: __copy_from_user_inatomic: ret=%d\n", ret); > > pagefault_enable(); > > set_fs(old_fs); > > > > + if (ret) { > > + set_fs(USER_DS); > > + pagefault_disable(); > > + ret = __copy_from_user_inatomic(dst, > > + (__force const void __user *)src, size); > > + trace_printk("RETRY WITH USER_DS: __copy_from_user_inatomic: ret=%d\n", ret); > > + pagefault_enable(); > > + set_fs(old_fs); > > + } > > + > > return ret ? -EFAULT : 0; > > } > > EXPORT_SYMBOL_GPL(probe_kernel_read); > > > > In initially thought this was because of the addr_limit pointer masking done > > by this patch from Mark Rutland "arm64: Use pointer masking to limit uaccess > > speculation" > > > > However removing this masking still makes it fail with KERNEL_DS. > > > > Fwiw, I am still curious which other paths in arm64 check the addr_limit > > which might make the __copy_from_user_inatomic fail if the set_fs is not > > setup correctly. > > > > Either way, I will resubmit the patch with the commit message fixed correctly > > as we agreed and also address Alexei's comments. > > I'm coming at this with no background, so it's tricky to understand exactly > what's going on here. Some questions: No problem, I added you out of the blue so it is quite understandable :) > * Are you seeing a failure with mainline and/or an official stable kernel? This issue is noticed on the Pixel3 kernel (4.9 based): git clone https://android.googlesource.com/kernel/msm (branch: android-msm-crosshatch-4.9-q-preview-1) > * What is the failing CPU? (so we can figure out which architectural > extensions are implemented) From cpuinfo: AArch64 Processor rev 12 (aarch64) (Qualcomm SDM845 SoC). It is a Pixel 3 phone. > * Do you have a .config anywhere? Particular, how are ARM64_PAN, > ARM64_TTBR0_PAN and ARM64_UAO set? CONFIG_ARM64_SW_TTBR0_PAN is not set CONFIG_ARM64_PAN=y CONFIG_ARM64_UAO=y I wanted to say I enabled SW_TTBR0_PAN config and also got the same result. > * Is the address being accessed a user or a kernel address? User. It is the second argument of do_sys_open() kernel function. kprobe gives bpf the pointer which the bpf program dereferences with probe_kernel_read. > If you're trying to dereference a pointer to userspace using > probe_kernel_read(), that clearly isn't going to work. Ok. Thanks for confirming as well. The existing code has this bug and these patches fix it. - Joel