From mboxrd@z Thu Jan 1 00:00:00 1970 From: Evgenii Stepanov Subject: Re: [PATCH v7 0/8] arm64: untag user pointers passed to the kernel Date: Wed, 17 Oct 2018 13:25:42 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andrey Konovalov Cc: Vincenzo Frascino , Catalin Marinas , Will Deacon , Mark Rutland , Robin Murphy , Kees Cook , Kate Stewart , Greg Kroah-Hartman , Andrew Morton , Ingo Molnar , "Kirill A . Shutemov" , Shuah Khan , Linux ARM , "open list:DOCUMENTATION" , Linux Memory Management List , linux-arch , "open list:KERNEL SELFTEST FRAMEWORK" List-Id: linux-arch.vger.kernel.org On Wed, Oct 17, 2018 at 7:20 AM, Andrey Konovalov w= rote: > On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino > wrote: >> Hi Andrey, >> I have been thinking a bit lately on how to address the problem of user = tagged pointers passed to the kernel through syscalls, and IMHO probably th= e best way we have to catch them all and make sure that the approach is mai= ntainable in the long term is to introduce shims that tag/untag the pointer= s passed to the kernel. >> >> In details, what I am proposing can live either in userspace (preferred = solution so that we do not have to relax the ABI) or in kernel space and ca= n be summarized as follows: >> - A shim is specific to a syscall and is called by the libc when it nee= ds to invoke the respective syscall. >> - It is required only if the syscall accepts pointers. >> - It saves the tags of a pointers passed to the syscall in memory (same= approach if the we are passing a struct that contains pointers to the kern= el, with the difference that all the tags of the pointers in the struct nee= d to be saved singularly) >> - Untags the pointers >> - Invokes the syscall >> - Retags the pointers with the tags stored in memory >> - Returns >> >> What do you think? > > Hi Vincenzo, > > If I correctly understand what you are proposing, I'm not sure if that > would work with the countless number of different ioctl calls. For > example when an ioctl accepts a struct with a bunch of pointer fields. > In this case a shim like the one you propose can't live in userspace, > since libc doesn't know about the interface of all ioctls, so it can't > know which fields to untag. The kernel knows about those interfaces > (since the kernel implements them), but then we would need a custom > shim for each ioctl variation, which doesn't seem practical. The current patchset handles majority of pointers in a just a few common places, like copy_from_user. Userspace shims will need to untag & retag all pointer arguments - we are looking at hundreds if not thousands of shims. They will also be located in a different code base from the syscall / ioctl implementations, which would make them impossible to keep up to date. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-f65.google.com ([209.85.217.65]:37447 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725745AbeJREXE (ORCPT ); Thu, 18 Oct 2018 00:23:04 -0400 Received: by mail-vs1-f65.google.com with SMTP id r83so21636665vsc.4 for ; Wed, 17 Oct 2018 13:25:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Evgenii Stepanov Date: Wed, 17 Oct 2018 13:25:42 -0700 Message-ID: Subject: Re: [PATCH v7 0/8] arm64: untag user pointers passed to the kernel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andrey Konovalov Cc: Vincenzo Frascino , Catalin Marinas , Will Deacon , Mark Rutland , Robin Murphy , Kees Cook , Kate Stewart , Greg Kroah-Hartman , Andrew Morton , Ingo Molnar , "Kirill A . Shutemov" , Shuah Khan , Linux ARM , "open list:DOCUMENTATION" , Linux Memory Management List , linux-arch , "open list:KERNEL SELFTEST FRAMEWORK" , LKML , Chintan Pandya , Jacob Bramley , Ruben Ayrapetyan , Lee Smith , Kostya Serebryany , Dmitry Vyukov , Ramana Radhakrishnan , Luc Van Oostenryck Message-ID: <20181017202542.sArvK7lVk4MTOHnt0SDhw1y1OlaH8qqgp_L3GWhNYfc@z> On Wed, Oct 17, 2018 at 7:20 AM, Andrey Konovalov w= rote: > On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino > wrote: >> Hi Andrey, >> I have been thinking a bit lately on how to address the problem of user = tagged pointers passed to the kernel through syscalls, and IMHO probably th= e best way we have to catch them all and make sure that the approach is mai= ntainable in the long term is to introduce shims that tag/untag the pointer= s passed to the kernel. >> >> In details, what I am proposing can live either in userspace (preferred = solution so that we do not have to relax the ABI) or in kernel space and ca= n be summarized as follows: >> - A shim is specific to a syscall and is called by the libc when it nee= ds to invoke the respective syscall. >> - It is required only if the syscall accepts pointers. >> - It saves the tags of a pointers passed to the syscall in memory (same= approach if the we are passing a struct that contains pointers to the kern= el, with the difference that all the tags of the pointers in the struct nee= d to be saved singularly) >> - Untags the pointers >> - Invokes the syscall >> - Retags the pointers with the tags stored in memory >> - Returns >> >> What do you think? > > Hi Vincenzo, > > If I correctly understand what you are proposing, I'm not sure if that > would work with the countless number of different ioctl calls. For > example when an ioctl accepts a struct with a bunch of pointer fields. > In this case a shim like the one you propose can't live in userspace, > since libc doesn't know about the interface of all ioctls, so it can't > know which fields to untag. The kernel knows about those interfaces > (since the kernel implements them), but then we would need a custom > shim for each ioctl variation, which doesn't seem practical. The current patchset handles majority of pointers in a just a few common places, like copy_from_user. Userspace shims will need to untag & retag all pointer arguments - we are looking at hundreds if not thousands of shims. They will also be located in a different code base from the syscall / ioctl implementations, which would make them impossible to keep up to date.