From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Konovalov Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel Date: Fri, 31 May 2019 16:29:10 +0200 Message-ID: References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> <201905211633.6C0BF0C2@keescook> <6049844a-65f5-f513-5b58-7141588fef2b@oracle.com> <20190523201105.oifkksus4rzcwqt4@mbp> <20190524101139.36yre4af22bkvatx@mbp> <20190530171540.GD35418@arrakis.emea.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20190530171540.GD35418@arrakis.emea.arm.com> Sender: linux-kernel-owner@vger.kernel.org To: Catalin Marinas Cc: Kees Cook , Evgenii Stepanov , Linux ARM , Linux Memory Management List , LKML , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, linux-media@vger.kernel.org, kvm@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Will Deacon , Mark Rutland , Andrew Morton , Greg Kroah-Hartman , Yishai Hadas , Felix Kuehling , Alexander Deucher List-Id: linux-rdma@vger.kernel.org On Thu, May 30, 2019 at 7:15 PM Catalin Marinas wrote: > > On Tue, May 28, 2019 at 04:14:45PM +0200, Andrey Konovalov wrote: > > Thanks for a lot of valuable input! I've read through all the replies > > and got somewhat lost. What are the changes I need to do to this > > series? > > > > 1. Should I move untagging for memory syscalls back to the generic > > code so other arches would make use of it as well, or should I keep > > the arm64 specific memory syscalls wrappers and address the comments > > on that patch? > > Keep them generic again but make sure we get agreement with Khalid on > the actual ABI implications for sparc. OK, will do. I find it hard to understand what the ABI implications are. I'll post the next version without untagging in brk, mmap, munmap, mremap (for new_address), mmap_pgoff, remap_file_pages, shmat and shmdt. > > > 2. Should I make untagging opt-in and controlled by a command line argument? > > Opt-in, yes, but per task rather than kernel command line option. > prctl() is a possibility of opting in. OK. Should I store a flag somewhere in task_struct? Should it be inheritable on clone? > > > 3. Should I "add Documentation/core-api/user-addresses.rst to describe > > proper care and handling of user space pointers with untagged_addr(), > > with examples based on all the cases seen so far in this series"? > > Which examples specifically should it cover? > > I think we can leave 3 for now as not too urgent. What I'd like is for > Vincenzo's TBI user ABI document to go into a more common place since we > can expand it to cover both sparc and arm64. We'd need an arm64-specific > doc as well for things like prctl() and later MTE that sparc may support > differently. OK. > > -- > Catalin 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=-8.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_MED,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 2A735C04AB6 for ; Fri, 31 May 2019 14:29:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F36A726A9A for ; Fri, 31 May 2019 14:29:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sQG2/gyF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726721AbfEaO3X (ORCPT ); Fri, 31 May 2019 10:29:23 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:44728 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726547AbfEaO3W (ORCPT ); Fri, 31 May 2019 10:29:22 -0400 Received: by mail-pl1-f195.google.com with SMTP id c5so4078601pll.11 for ; Fri, 31 May 2019 07:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=evy368hWiI+gBYUbtpZ/Z/NwaFGt0gP/Ku0Se7jRDIs=; b=sQG2/gyFbhvQgnnYVMoq8Kda68VVztjS6NpVGpn+TJ/0x1CnUPLFGI7CfwhDx4Acpv +b2SfJPlJiXKHOPX0vraeScgQBz7b7Nl6PyJKu6e145lCoysI0y6J5myuuCSNlucfPw4 OziFqAsvBRMmxzPBSxXT6y9ZOWT1qftFo2UhubNHkIM+xAKIuSxRN1IDkqLlB5D+IEDh 9Lbkk942zOUUnqGLz1d6wvbTAZV2QEf8AYds1RPyvHK7XFYBgL+gUTiPMyMH1+mL85z0 rHLvvgL9h/d8SCsWwDzjC1mOEMEITHFigTDJGZoVkvgiZ6th+Bg/aZrVlKENNn6Dl+G9 3qvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=evy368hWiI+gBYUbtpZ/Z/NwaFGt0gP/Ku0Se7jRDIs=; b=gBIzXxu7OOOgZYohRGlWxIYrOg9ZKmLhQyQxjzhUWeAZiCOxiA6WJMc9yLDutvdAyY lTLgB5lZmAjNL4N/D7S5jJgzOWOmhtUHCiGbIUxo0TZm4m3eu5i7VgwPpAIkA64bgKuO rC/4Zgb9MWRhzvTmv4qStUSp7TfzelT1GIyNrB5xvi6UZqTio6os4acGIbNpFCL9yusk fXIPikcqjIU/bwCr/vPAWW5pOYyOwT84EcxQ0N6BK5lP+f4gc8ip6O8NeqczLVkHYHAW 5SAaNHUAg0LnstABcYpJTMUYFTuICUNu9Vv4LccaYWY8kvqNd+oAePlP22wH5N4obzhh KpVQ== X-Gm-Message-State: APjAAAXrFPdriXYH7eGHoIzDhKemIslwlGWegx2vSyQ5n+n0sxoFvpub O/BDqbgg4nX1B2puryx8zgd1arbISDYTuR5AYIzIOw== X-Google-Smtp-Source: APXvYqzZNq7ZmlghEU+anyWYnwjjhfBSO821IIVYI0unmJhzupp13rZUJ7jf2s8ZHPUTRKkSRgHsOXgkfcRcIwbO8eo= X-Received: by 2002:a17:902:8609:: with SMTP id f9mr9244481plo.252.1559312961740; Fri, 31 May 2019 07:29:21 -0700 (PDT) MIME-Version: 1.0 References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> <201905211633.6C0BF0C2@keescook> <6049844a-65f5-f513-5b58-7141588fef2b@oracle.com> <20190523201105.oifkksus4rzcwqt4@mbp> <20190524101139.36yre4af22bkvatx@mbp> <20190530171540.GD35418@arrakis.emea.arm.com> In-Reply-To: <20190530171540.GD35418@arrakis.emea.arm.com> From: Andrey Konovalov Date: Fri, 31 May 2019 16:29:10 +0200 Message-ID: Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel To: Catalin Marinas Cc: Kees Cook , Evgenii Stepanov , Linux ARM , Linux Memory Management List , LKML , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, linux-media@vger.kernel.org, kvm@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Will Deacon , Mark Rutland , Andrew Morton , Greg Kroah-Hartman , Yishai Hadas , Felix Kuehling , Alexander Deucher , Christian Koenig , Mauro Carvalho Chehab , Jens Wiklander , Alex Williamson , Leon Romanovsky , Dmitry Vyukov , Kostya Serebryany , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Robin Murphy , Luc Van Oostenryck , Dave Martin , Kevin Brodsky , Szabolcs Nagy , Elliott Hughes , Khalid Aziz Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 30, 2019 at 7:15 PM Catalin Marinas wrote: > > On Tue, May 28, 2019 at 04:14:45PM +0200, Andrey Konovalov wrote: > > Thanks for a lot of valuable input! I've read through all the replies > > and got somewhat lost. What are the changes I need to do to this > > series? > > > > 1. Should I move untagging for memory syscalls back to the generic > > code so other arches would make use of it as well, or should I keep > > the arm64 specific memory syscalls wrappers and address the comments > > on that patch? > > Keep them generic again but make sure we get agreement with Khalid on > the actual ABI implications for sparc. OK, will do. I find it hard to understand what the ABI implications are. I'll post the next version without untagging in brk, mmap, munmap, mremap (for new_address), mmap_pgoff, remap_file_pages, shmat and shmdt. > > > 2. Should I make untagging opt-in and controlled by a command line argument? > > Opt-in, yes, but per task rather than kernel command line option. > prctl() is a possibility of opting in. OK. Should I store a flag somewhere in task_struct? Should it be inheritable on clone? > > > 3. Should I "add Documentation/core-api/user-addresses.rst to describe > > proper care and handling of user space pointers with untagged_addr(), > > with examples based on all the cases seen so far in this series"? > > Which examples specifically should it cover? > > I think we can leave 3 for now as not too urgent. What I'd like is for > Vincenzo's TBI user ABI document to go into a more common place since we > can expand it to cover both sparc and arm64. We'd need an arm64-specific > doc as well for things like prctl() and later MTE that sparc may support > differently. OK. > > -- > Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: andreyknvl at google.com (Andrey Konovalov) Date: Fri, 31 May 2019 16:29:10 +0200 Subject: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel In-Reply-To: <20190530171540.GD35418@arrakis.emea.arm.com> References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> <201905211633.6C0BF0C2@keescook> <6049844a-65f5-f513-5b58-7141588fef2b@oracle.com> <20190523201105.oifkksus4rzcwqt4@mbp> <20190524101139.36yre4af22bkvatx@mbp> <20190530171540.GD35418@arrakis.emea.arm.com> Message-ID: On Thu, May 30, 2019 at 7:15 PM Catalin Marinas wrote: > > On Tue, May 28, 2019 at 04:14:45PM +0200, Andrey Konovalov wrote: > > Thanks for a lot of valuable input! I've read through all the replies > > and got somewhat lost. What are the changes I need to do to this > > series? > > > > 1. Should I move untagging for memory syscalls back to the generic > > code so other arches would make use of it as well, or should I keep > > the arm64 specific memory syscalls wrappers and address the comments > > on that patch? > > Keep them generic again but make sure we get agreement with Khalid on > the actual ABI implications for sparc. OK, will do. I find it hard to understand what the ABI implications are. I'll post the next version without untagging in brk, mmap, munmap, mremap (for new_address), mmap_pgoff, remap_file_pages, shmat and shmdt. > > > 2. Should I make untagging opt-in and controlled by a command line argument? > > Opt-in, yes, but per task rather than kernel command line option. > prctl() is a possibility of opting in. OK. Should I store a flag somewhere in task_struct? Should it be inheritable on clone? > > > 3. Should I "add Documentation/core-api/user-addresses.rst to describe > > proper care and handling of user space pointers with untagged_addr(), > > with examples based on all the cases seen so far in this series"? > > Which examples specifically should it cover? > > I think we can leave 3 for now as not too urgent. What I'd like is for > Vincenzo's TBI user ABI document to go into a more common place since we > can expand it to cover both sparc and arm64. We'd need an arm64-specific > doc as well for things like prctl() and later MTE that sparc may support > differently. OK. > > -- > Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: andreyknvl@google.com (Andrey Konovalov) Date: Fri, 31 May 2019 16:29:10 +0200 Subject: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel In-Reply-To: <20190530171540.GD35418@arrakis.emea.arm.com> References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> <201905211633.6C0BF0C2@keescook> <6049844a-65f5-f513-5b58-7141588fef2b@oracle.com> <20190523201105.oifkksus4rzcwqt4@mbp> <20190524101139.36yre4af22bkvatx@mbp> <20190530171540.GD35418@arrakis.emea.arm.com> Message-ID: Content-Type: text/plain; charset="UTF-8" Message-ID: <20190531142910.RYaBBC9GREqlY_nRm8vZ8JqinWmEJAtkt7mPMKh9IXA@z> On Thu, May 30, 2019@7:15 PM Catalin Marinas wrote: > > On Tue, May 28, 2019@04:14:45PM +0200, Andrey Konovalov wrote: > > Thanks for a lot of valuable input! I've read through all the replies > > and got somewhat lost. What are the changes I need to do to this > > series? > > > > 1. Should I move untagging for memory syscalls back to the generic > > code so other arches would make use of it as well, or should I keep > > the arm64 specific memory syscalls wrappers and address the comments > > on that patch? > > Keep them generic again but make sure we get agreement with Khalid on > the actual ABI implications for sparc. OK, will do. I find it hard to understand what the ABI implications are. I'll post the next version without untagging in brk, mmap, munmap, mremap (for new_address), mmap_pgoff, remap_file_pages, shmat and shmdt. > > > 2. Should I make untagging opt-in and controlled by a command line argument? > > Opt-in, yes, but per task rather than kernel command line option. > prctl() is a possibility of opting in. OK. Should I store a flag somewhere in task_struct? Should it be inheritable on clone? > > > 3. Should I "add Documentation/core-api/user-addresses.rst to describe > > proper care and handling of user space pointers with untagged_addr(), > > with examples based on all the cases seen so far in this series"? > > Which examples specifically should it cover? > > I think we can leave 3 for now as not too urgent. What I'd like is for > Vincenzo's TBI user ABI document to go into a more common place since we > can expand it to cover both sparc and arm64. We'd need an arm64-specific > doc as well for things like prctl() and later MTE that sparc may support > differently. OK. > > -- > Catalin 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=-8.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_MED,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 13DC7C28CC2 for ; Fri, 31 May 2019 14:29:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D0A3D26AA1 for ; Fri, 31 May 2019 14:29:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sQG2/gyF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0A3D26AA1 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6134D6B026F; Fri, 31 May 2019 10:29:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C4076B0278; Fri, 31 May 2019 10:29:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B3596B027A; Fri, 31 May 2019 10:29:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by kanga.kvack.org (Postfix) with ESMTP id 133E36B026F for ; Fri, 31 May 2019 10:29:24 -0400 (EDT) Received: by mail-pl1-f197.google.com with SMTP id o12so6405172pll.17 for ; Fri, 31 May 2019 07:29:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:mime-version:references :in-reply-to:from:date:message-id:subject:to:cc; bh=evy368hWiI+gBYUbtpZ/Z/NwaFGt0gP/Ku0Se7jRDIs=; b=tknx3dyO0nCfxAGW787e4nLxSB5ywBo4tZJjcrLdw911qbfkF6H49IQ+Z/SM+UwDIj f2Hao3x1W+NZHqXc+9qopzDyOtn3/L4ZGBw4jkgpRdi8yWqT0aA9mwe/kHtnVSRmHpyQ HDMPYt1xaQw4VPX+KP27+6IPNsjmbv3rXiHu2QlxxmLAkDc+DxYKA8ASE9UEllf+0qRk tWRH8Mf7HEeh7SPCrtf8zbgJkAWOL/PzqR3/0VPu/SDyzLKnXusru4oVHwldn2sDQWL3 CaCMwLwpRF7UAjstxE5008nxDcX50xDnFtHCclri4Yds7h40hKRoCkB091afB97MrSGJ 5nxQ== X-Gm-Message-State: APjAAAVF4PFzRXVoORHIUQLioeyOMWD6bRHp9lczTd+rUpHWLF4tAabV 0fPC9gkoQR65phIfpQ9Tg2y42x1POL7sMpeb2dMn+Bmhik2MFhwHbEFXdh5gHnizjtOLdsBbQ6W p2F3cBoxZF0v/3hX7gtGueWO5ZcfvZOlRf96m+eUBP9cDKOk11nFSo8E8TFK0taKiiQ== X-Received: by 2002:a63:6f8d:: with SMTP id k135mr5450841pgc.118.1559312963535; Fri, 31 May 2019 07:29:23 -0700 (PDT) X-Received: by 2002:a63:6f8d:: with SMTP id k135mr5450750pgc.118.1559312962501; Fri, 31 May 2019 07:29:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559312962; cv=none; d=google.com; s=arc-20160816; b=MnGiIOkeNWdkDNBBG3iMt2htkMggVDnA4hpaOkWeHIgNiyIpmKukGgFAp48ayw7MIO 7cecjuF6pi42wDpbudj9mZw5cYW5Yzs1RRBcciD6HVJ30UX9Jy4mmI3KLLuXYvpriaGt Tl4kZ97bOz3eCEMo93ZJe5DlvdWBy2qX55GleLU1LAnGrC6lD19Qn/i0bqZZTyb1Pd9I ADvFY2TGYU6BbR7GPqC1UjaXEfPZLdXxQ21mg0Z5x4PA5GXHhdcWK8Qfgxij338y0n2a 31+tMVZYooC9QbsyDf1AGZrZIy3OpriTytwEllG+0wBcPeElCfO+TngPjqpsmQAnL9Re Y0MQ== 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:in-reply-to:references :mime-version:dkim-signature; bh=evy368hWiI+gBYUbtpZ/Z/NwaFGt0gP/Ku0Se7jRDIs=; b=Xx7U/mrYmOEvODiccf1D17RpTAFlDoBndbFIZWy8Df7uZ+jzVO3dbm/t4vW2EUeRQb D3XNnne042yFgSdOrZ7Pp9H6vhBlyphjGAPCajXYIjHkZclKZjzMUB4xPqB/3nwSAuy3 HNhSppoDzqPaMi2pU15vv+xrBedPWoawM1qTYZeGmFHKp6W+OhVwQERegqJMsts99E/x eKk3HT73eCVN0c8EUZHlpNJ4M9WNehHrCjqLALDKz6ygch5dPMZR+Sgnw4l4eeMbe7Q1 sltfvWCVP/QHyLwz3laCboXLiHBc1cx25Z7aHnmTvfxa1aP0/FTeTQb3kJd6P7+IiGdO d9GQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="sQG2/gyF"; spf=pass (google.com: domain of andreyknvl@google.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=andreyknvl@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id l96sor6818225plb.68.2019.05.31.07.29.22 for (Google Transport Security); Fri, 31 May 2019 07:29:22 -0700 (PDT) Received-SPF: pass (google.com: domain of andreyknvl@google.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="sQG2/gyF"; spf=pass (google.com: domain of andreyknvl@google.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=andreyknvl@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=evy368hWiI+gBYUbtpZ/Z/NwaFGt0gP/Ku0Se7jRDIs=; b=sQG2/gyFbhvQgnnYVMoq8Kda68VVztjS6NpVGpn+TJ/0x1CnUPLFGI7CfwhDx4Acpv +b2SfJPlJiXKHOPX0vraeScgQBz7b7Nl6PyJKu6e145lCoysI0y6J5myuuCSNlucfPw4 OziFqAsvBRMmxzPBSxXT6y9ZOWT1qftFo2UhubNHkIM+xAKIuSxRN1IDkqLlB5D+IEDh 9Lbkk942zOUUnqGLz1d6wvbTAZV2QEf8AYds1RPyvHK7XFYBgL+gUTiPMyMH1+mL85z0 rHLvvgL9h/d8SCsWwDzjC1mOEMEITHFigTDJGZoVkvgiZ6th+Bg/aZrVlKENNn6Dl+G9 3qvw== X-Google-Smtp-Source: APXvYqzZNq7ZmlghEU+anyWYnwjjhfBSO821IIVYI0unmJhzupp13rZUJ7jf2s8ZHPUTRKkSRgHsOXgkfcRcIwbO8eo= X-Received: by 2002:a17:902:8609:: with SMTP id f9mr9244481plo.252.1559312961740; Fri, 31 May 2019 07:29:21 -0700 (PDT) MIME-Version: 1.0 References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> <201905211633.6C0BF0C2@keescook> <6049844a-65f5-f513-5b58-7141588fef2b@oracle.com> <20190523201105.oifkksus4rzcwqt4@mbp> <20190524101139.36yre4af22bkvatx@mbp> <20190530171540.GD35418@arrakis.emea.arm.com> In-Reply-To: <20190530171540.GD35418@arrakis.emea.arm.com> From: Andrey Konovalov Date: Fri, 31 May 2019 16:29:10 +0200 Message-ID: Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel To: Catalin Marinas Cc: Kees Cook , Evgenii Stepanov , Linux ARM , Linux Memory Management List , LKML , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, linux-media@vger.kernel.org, kvm@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Will Deacon , Mark Rutland , Andrew Morton , Greg Kroah-Hartman , Yishai Hadas , Felix Kuehling , Alexander Deucher , Christian Koenig , Mauro Carvalho Chehab , Jens Wiklander , Alex Williamson , Leon Romanovsky , Dmitry Vyukov , Kostya Serebryany , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Robin Murphy , Luc Van Oostenryck , Dave Martin , Kevin Brodsky , Szabolcs Nagy , Elliott Hughes , Khalid Aziz Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, May 30, 2019 at 7:15 PM Catalin Marinas wrote: > > On Tue, May 28, 2019 at 04:14:45PM +0200, Andrey Konovalov wrote: > > Thanks for a lot of valuable input! I've read through all the replies > > and got somewhat lost. What are the changes I need to do to this > > series? > > > > 1. Should I move untagging for memory syscalls back to the generic > > code so other arches would make use of it as well, or should I keep > > the arm64 specific memory syscalls wrappers and address the comments > > on that patch? > > Keep them generic again but make sure we get agreement with Khalid on > the actual ABI implications for sparc. OK, will do. I find it hard to understand what the ABI implications are. I'll post the next version without untagging in brk, mmap, munmap, mremap (for new_address), mmap_pgoff, remap_file_pages, shmat and shmdt. > > > 2. Should I make untagging opt-in and controlled by a command line argument? > > Opt-in, yes, but per task rather than kernel command line option. > prctl() is a possibility of opting in. OK. Should I store a flag somewhere in task_struct? Should it be inheritable on clone? > > > 3. Should I "add Documentation/core-api/user-addresses.rst to describe > > proper care and handling of user space pointers with untagged_addr(), > > with examples based on all the cases seen so far in this series"? > > Which examples specifically should it cover? > > I think we can leave 3 for now as not too urgent. What I'd like is for > Vincenzo's TBI user ABI document to go into a more common place since we > can expand it to cover both sparc and arm64. We'd need an arm64-specific > doc as well for things like prctl() and later MTE that sparc may support > differently. OK. > > -- > Catalin 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=-1.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED 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 1E01DC04AB6 for ; Fri, 31 May 2019 14:29:33 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E779426AA1 for ; Fri, 31 May 2019 14:29:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oVHBVOmm"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="sQG2/gyF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E779426AA1 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DW4M/M5XvTPYCN+JC/sjYjA0bZLCczG2U22pRstU5ts=; b=oVHBVOmmMVJ8Bf aVFukIq8wT9jRU1fnU0jMtM+160vsefZ00UMzE1Mnm18NtJsYjmzz/rLjIv1QQe6leZFY/FulC5bh /V+vcxtb8Df0GjrCGTiTrRylhpkBtf2htxfQ02vE5suRy89JzLc9mN1jXKCyLXF8yq0/10DEoIOlt 7Hv1PNktTrd7t247vRPalOYCYnP3cIxlWalSWn7XX5I4JnkZp2wrgcnp2IY5CMQAiNHlPzqfVWDws MxQwzuoCULzDUbQj+uumU0MPkvgkKpc+g8hhHWteBLiBdvswN/rlFE4jpa0KZL0GX7zumW7SQ+xTE XloKT2OYZpoKKHK30wWQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hWiXB-0004mG-9E; Fri, 31 May 2019 14:29:29 +0000 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hWiX8-0004lC-59 for linux-arm-kernel@lists.infradead.org; Fri, 31 May 2019 14:29:27 +0000 Received: by mail-pl1-x641.google.com with SMTP id g69so4089712plb.7 for ; Fri, 31 May 2019 07:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=evy368hWiI+gBYUbtpZ/Z/NwaFGt0gP/Ku0Se7jRDIs=; b=sQG2/gyFbhvQgnnYVMoq8Kda68VVztjS6NpVGpn+TJ/0x1CnUPLFGI7CfwhDx4Acpv +b2SfJPlJiXKHOPX0vraeScgQBz7b7Nl6PyJKu6e145lCoysI0y6J5myuuCSNlucfPw4 OziFqAsvBRMmxzPBSxXT6y9ZOWT1qftFo2UhubNHkIM+xAKIuSxRN1IDkqLlB5D+IEDh 9Lbkk942zOUUnqGLz1d6wvbTAZV2QEf8AYds1RPyvHK7XFYBgL+gUTiPMyMH1+mL85z0 rHLvvgL9h/d8SCsWwDzjC1mOEMEITHFigTDJGZoVkvgiZ6th+Bg/aZrVlKENNn6Dl+G9 3qvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=evy368hWiI+gBYUbtpZ/Z/NwaFGt0gP/Ku0Se7jRDIs=; b=aTD14s+n/HPoggsIXUHyqgA13p0alGCXztNRJ/NSlYYIyXlB067nhXHpJA1QX9DvX/ T/v/Vu3StNB+G9yxa8236cagNCMAarFu0DUtLxipw4m9eDJ2RLf/qZ0Bu1CA5wrmMjre PeDW2SElr5Q8wLG60pNOc9vSUBqHCn4sRLiGnv/z8XoFXCEg7vkGSIpF2ViTd/lP3UDm 7nxXtidE8pmpDtOJtRKkRm0r0nvzMxtfXOXDcdorbeRa8coBfyNM3rF3o1CfEqQRxuYT a5qaLs0w0JKZoo0W/03w8bqLdJivqgLJ11OfblpsyGoe4W3ac3nbJXxi4VUPva+dcKRQ bzBA== X-Gm-Message-State: APjAAAUZXKdIGtBwbv0qpJTwvXQMQ2qhZcUw84NtAjIL+LItzBMO9XVc X4wwtiVNj75aux79CHOZloLtYPqbyqTFrNN3w8u9DQ== X-Google-Smtp-Source: APXvYqzZNq7ZmlghEU+anyWYnwjjhfBSO821IIVYI0unmJhzupp13rZUJ7jf2s8ZHPUTRKkSRgHsOXgkfcRcIwbO8eo= X-Received: by 2002:a17:902:8609:: with SMTP id f9mr9244481plo.252.1559312961740; Fri, 31 May 2019 07:29:21 -0700 (PDT) MIME-Version: 1.0 References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> <201905211633.6C0BF0C2@keescook> <6049844a-65f5-f513-5b58-7141588fef2b@oracle.com> <20190523201105.oifkksus4rzcwqt4@mbp> <20190524101139.36yre4af22bkvatx@mbp> <20190530171540.GD35418@arrakis.emea.arm.com> In-Reply-To: <20190530171540.GD35418@arrakis.emea.arm.com> From: Andrey Konovalov Date: Fri, 31 May 2019 16:29:10 +0200 Message-ID: Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel To: Catalin Marinas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190531_072926_209030_B1628ABC X-CRM114-Status: GOOD ( 20.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , kvm@vger.kernel.org, Szabolcs Nagy , Will Deacon , dri-devel@lists.freedesktop.org, Linux Memory Management List , Khalid Aziz , "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Dmitry Vyukov , Dave Martin , Evgenii Stepanov , linux-media@vger.kernel.org, Kevin Brodsky , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Alex Williamson , Yishai Hadas , Mauro Carvalho Chehab , Linux ARM , Kostya Serebryany , Greg Kroah-Hartman , Felix Kuehling , LKML , Jens Wiklander , Lee Smith , Alexander Deucher , Andrew Morton , Elliott Hughes , Robin Murphy , Christian Koenig , Luc Van Oostenryck Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, May 30, 2019 at 7:15 PM Catalin Marinas wrote: > > On Tue, May 28, 2019 at 04:14:45PM +0200, Andrey Konovalov wrote: > > Thanks for a lot of valuable input! I've read through all the replies > > and got somewhat lost. What are the changes I need to do to this > > series? > > > > 1. Should I move untagging for memory syscalls back to the generic > > code so other arches would make use of it as well, or should I keep > > the arm64 specific memory syscalls wrappers and address the comments > > on that patch? > > Keep them generic again but make sure we get agreement with Khalid on > the actual ABI implications for sparc. OK, will do. I find it hard to understand what the ABI implications are. I'll post the next version without untagging in brk, mmap, munmap, mremap (for new_address), mmap_pgoff, remap_file_pages, shmat and shmdt. > > > 2. Should I make untagging opt-in and controlled by a command line argument? > > Opt-in, yes, but per task rather than kernel command line option. > prctl() is a possibility of opting in. OK. Should I store a flag somewhere in task_struct? Should it be inheritable on clone? > > > 3. Should I "add Documentation/core-api/user-addresses.rst to describe > > proper care and handling of user space pointers with untagged_addr(), > > with examples based on all the cases seen so far in this series"? > > Which examples specifically should it cover? > > I think we can leave 3 for now as not too urgent. What I'd like is for > Vincenzo's TBI user ABI document to go into a more common place since we > can expand it to cover both sparc and arm64. We'd need an arm64-specific > doc as well for things like prctl() and later MTE that sparc may support > differently. OK. > > -- > Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel