From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel Date: Wed, 22 May 2019 21:20:52 -0300 Message-ID: <20190523002052.GF15389@ziepe.ca> References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521184856.GC2922@ziepe.ca> <20190522134925.GV28398@e103592.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190522134925.GV28398@e103592.cambridge.arm.com> Sender: linux-kernel-owner@vger.kernel.org To: Dave Martin Cc: Catalin Marinas , Mark Rutland , kvm@vger.kernel.org, Szabolcs Nagy , Will Deacon , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Felix Kuehling , Vincenzo Frascino , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Dmitry Vyukov , Evgeniy Stepanov , linux-media@vger.kernel.org, Kevin Brodsky , Kees Cook , Ruben Ayrapetyan , Andrey Konovalov , Ramana List-Id: amd-gfx.lists.freedesktop.org On Wed, May 22, 2019 at 02:49:28PM +0100, Dave Martin wrote: > On Tue, May 21, 2019 at 03:48:56PM -0300, Jason Gunthorpe wrote: > > On Fri, May 17, 2019 at 03:49:31PM +0100, Catalin Marinas wrote: > > > > > The tagged pointers (whether hwasan or MTE) should ideally be a > > > transparent feature for the application writer but I don't think we can > > > solve it entirely and make it seamless for the multitude of ioctls(). > > > I'd say you only opt in to such feature if you know what you are doing > > > and the user code takes care of specific cases like ioctl(), hence the > > > prctl() proposal even for the hwasan. > > > > I'm not sure such a dire view is warrented.. > > > > The ioctl situation is not so bad, other than a few special cases, > > most drivers just take a 'void __user *' and pass it as an argument to > > some function that accepts a 'void __user *'. sparse et al verify > > this. > > > > As long as the core functions do the right thing the drivers will be > > OK. > > > > The only place things get dicy is if someone casts to unsigned long > > (ie for vma work) but I think that reflects that our driver facing > > APIs for VMAs are compatible with static analysis (ie I have no > > earthly idea why get_user_pages() accepts an unsigned long), not that > > this is too hard. > > If multiple people will care about this, perhaps we should try to > annotate types more explicitly in SYSCALL_DEFINEx() and ABI data > structures. > > For example, we could have a couple of mutually exclusive modifiers > > T __object * > T __vaddr * (or U __vaddr) > > In the first case the pointer points to an object (in the C sense) > that the call may dereference but not use for any other purpose. How would you use these two differently? So far the kernel has worked that __user should tag any pointer that is from userspace and then you can't do anything with it until you transform it into a kernel something > to tell static analysers the real type of pointers smuggled through > UAPI disguised as other types (*cough* KVM, etc.) Yes, that would help alot, we often have to pass pointers through a u64 in the uAPI, and there is no static checker support to make sure they are run through the u64_to_user_ptr() helper. Jason