From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59FE1C5ACCC for ; Thu, 18 Oct 2018 17:33:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0E41C20658 for ; Thu, 18 Oct 2018 17:33:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E41C20658 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728158AbeJSBfi (ORCPT ); Thu, 18 Oct 2018 21:35:38 -0400 Received: from foss.arm.com ([217.140.101.70]:41560 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726269AbeJSBfh (ORCPT ); Thu, 18 Oct 2018 21:35:37 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D355F341; Thu, 18 Oct 2018 10:33:37 -0700 (PDT) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.80]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 98F373F5D3; Thu, 18 Oct 2018 10:33:33 -0700 (PDT) Date: Thu, 18 Oct 2018 18:33:31 +0100 From: Catalin Marinas To: Evgenii Stepanov Cc: Andrey Konovalov , Mark Rutland , Kate Stewart , "open list:DOCUMENTATION" , Will Deacon , Linux Memory Management List , "open list:KERNEL SELFTEST FRAMEWORK" , Chintan Pandya , Vincenzo Frascino , Shuah Khan , Ingo Molnar , linux-arch , Jacob Bramley , Dmitry Vyukov , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Linux ARM , Kostya Serebryany , Greg Kroah-Hartman , LKML , Luc Van Oostenryck , Lee Smith , Andrew Morton , Robin Murphy , "Kirill A . Shutemov" Subject: Re: [PATCH v7 0/8] arm64: untag user pointers passed to the kernel Message-ID: <20181018173330.GG237391@arrakis.emea.arm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Oct 17, 2018 at 01:25:42PM -0700, Evgenii Stepanov wrote: > On Wed, Oct 17, 2018 at 7:20 AM, Andrey Konovalov wrote: > > On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino > > wrote: > >> 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 the best way we have to catch them all and make sure > >> that the approach is maintainable in the long term is to introduce > >> shims that tag/untag the pointers 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 can be summarized as follows: > >> - A shim is specific to a syscall and is called by the libc when > >> it needs 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 kernel, with the difference that all the tags of > >> the pointers in the struct need to be saved singularly) > >> - Untags the pointers > >> - Invokes the syscall > >> - Retags the pointers with the tags stored in memory > >> - Returns > >> > >> What do you think? > > > > 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. I think ioctls are a good reason not to attempt such user-space shim layer (though it would have been much easier for the kernel ;)). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas at arm.com (Catalin Marinas) Date: Thu, 18 Oct 2018 18:33:31 +0100 Subject: [PATCH v7 0/8] arm64: untag user pointers passed to the kernel In-Reply-To: References: Message-ID: <20181018173330.GG237391@arrakis.emea.arm.com> On Wed, Oct 17, 2018 at 01:25:42PM -0700, Evgenii Stepanov wrote: > On Wed, Oct 17, 2018 at 7:20 AM, Andrey Konovalov wrote: > > On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino > > wrote: > >> 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 the best way we have to catch them all and make sure > >> that the approach is maintainable in the long term is to introduce > >> shims that tag/untag the pointers 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 can be summarized as follows: > >> - A shim is specific to a syscall and is called by the libc when > >> it needs 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 kernel, with the difference that all the tags of > >> the pointers in the struct need to be saved singularly) > >> - Untags the pointers > >> - Invokes the syscall > >> - Retags the pointers with the tags stored in memory > >> - Returns > >> > >> What do you think? > > > > 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. I think ioctls are a good reason not to attempt such user-space shim layer (though it would have been much easier for the kernel ;)). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Thu, 18 Oct 2018 18:33:31 +0100 Subject: [PATCH v7 0/8] arm64: untag user pointers passed to the kernel In-Reply-To: References: Message-ID: <20181018173330.GG237391@arrakis.emea.arm.com> Content-Type: text/plain; charset="UTF-8" Message-ID: <20181018173331.-kZiYTQufBSNkVrR-fb4O8s8EuqgxbI6pGOICHSS2Zw@z> On Wed, Oct 17, 2018@01:25:42PM -0700, Evgenii Stepanov wrote: > On Wed, Oct 17, 2018@7:20 AM, Andrey Konovalov wrote: > > On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino > > wrote: > >> 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 the best way we have to catch them all and make sure > >> that the approach is maintainable in the long term is to introduce > >> shims that tag/untag the pointers 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 can be summarized as follows: > >> - A shim is specific to a syscall and is called by the libc when > >> it needs 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 kernel, with the difference that all the tags of > >> the pointers in the struct need to be saved singularly) > >> - Untags the pointers > >> - Invokes the syscall > >> - Retags the pointers with the tags stored in memory > >> - Returns > >> > >> What do you think? > > > > 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. I think ioctls are a good reason not to attempt such user-space shim layer (though it would have been much easier for the kernel ;)). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: [PATCH v7 0/8] arm64: untag user pointers passed to the kernel Date: Thu, 18 Oct 2018 18:33:31 +0100 Message-ID: <20181018173330.GG237391@arrakis.emea.arm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Evgenii Stepanov Cc: Andrey Konovalov , Mark Rutland , Kate Stewart , "open list:DOCUMENTATION" , Will Deacon , Linux Memory Management List , "open list:KERNEL SELFTEST FRAMEWORK" , Chintan Pandya , Vincenzo Frascino , Shuah Khan , Ingo Molnar , linux-arch , Jacob Bramley , Dmitry Vyukov , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Linux ARM List-Id: linux-arch.vger.kernel.org On Wed, Oct 17, 2018 at 01:25:42PM -0700, Evgenii Stepanov wrote: > On Wed, Oct 17, 2018 at 7:20 AM, Andrey Konovalov wrote: > > On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino > > wrote: > >> 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 the best way we have to catch them all and make sure > >> that the approach is maintainable in the long term is to introduce > >> shims that tag/untag the pointers 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 can be summarized as follows: > >> - A shim is specific to a syscall and is called by the libc when > >> it needs 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 kernel, with the difference that all the tags of > >> the pointers in the struct need to be saved singularly) > >> - Untags the pointers > >> - Invokes the syscall > >> - Retags the pointers with the tags stored in memory > >> - Returns > >> > >> What do you think? > > > > 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. I think ioctls are a good reason not to attempt such user-space shim layer (though it would have been much easier for the kernel ;)). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com ([217.140.101.70]:41560 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726269AbeJSBfh (ORCPT ); Thu, 18 Oct 2018 21:35:37 -0400 Date: Thu, 18 Oct 2018 18:33:31 +0100 From: Catalin Marinas Subject: Re: [PATCH v7 0/8] arm64: untag user pointers passed to the kernel Message-ID: <20181018173330.GG237391@arrakis.emea.arm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Evgenii Stepanov Cc: Andrey Konovalov , Mark Rutland , Kate Stewart , "open list:DOCUMENTATION" , Will Deacon , Linux Memory Management List , "open list:KERNEL SELFTEST FRAMEWORK" , Chintan Pandya , Vincenzo Frascino , Shuah Khan , Ingo Molnar , linux-arch , Jacob Bramley , Dmitry Vyukov , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Linux ARM , Kostya Serebryany , Greg Kroah-Hartman , LKML , Luc Van Oostenryck , Lee Smith , Andrew Morton , Robin Murphy , "Kirill A . Shutemov" Message-ID: <20181018173331.SeBl8kESQDrz5fHz1vzKI_8oQlbmm7xxy8LQPxUUxj4@z> On Wed, Oct 17, 2018 at 01:25:42PM -0700, Evgenii Stepanov wrote: > On Wed, Oct 17, 2018 at 7:20 AM, Andrey Konovalov wrote: > > On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino > > wrote: > >> 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 the best way we have to catch them all and make sure > >> that the approach is maintainable in the long term is to introduce > >> shims that tag/untag the pointers 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 can be summarized as follows: > >> - A shim is specific to a syscall and is called by the libc when > >> it needs 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 kernel, with the difference that all the tags of > >> the pointers in the struct need to be saved singularly) > >> - Untags the pointers > >> - Invokes the syscall > >> - Retags the pointers with the tags stored in memory > >> - Returns > >> > >> What do you think? > > > > 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. I think ioctls are a good reason not to attempt such user-space shim layer (though it would have been much easier for the kernel ;)). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Thu, 18 Oct 2018 18:33:31 +0100 Subject: [PATCH v7 0/8] arm64: untag user pointers passed to the kernel In-Reply-To: References: Message-ID: <20181018173330.GG237391@arrakis.emea.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Oct 17, 2018 at 01:25:42PM -0700, Evgenii Stepanov wrote: > On Wed, Oct 17, 2018 at 7:20 AM, Andrey Konovalov wrote: > > On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino > > wrote: > >> 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 the best way we have to catch them all and make sure > >> that the approach is maintainable in the long term is to introduce > >> shims that tag/untag the pointers 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 can be summarized as follows: > >> - A shim is specific to a syscall and is called by the libc when > >> it needs 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 kernel, with the difference that all the tags of > >> the pointers in the struct need to be saved singularly) > >> - Untags the pointers > >> - Invokes the syscall > >> - Retags the pointers with the tags stored in memory > >> - Returns > >> > >> What do you think? > > > > 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. I think ioctls are a good reason not to attempt such user-space shim layer (though it would have been much easier for the kernel ;)). -- Catalin