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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT 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 C1AEEC10F05 for ; Wed, 20 Mar 2019 11:25:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9D1312186A for ; Wed, 20 Mar 2019 11:25:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727944AbfCTLZ5 (ORCPT ); Wed, 20 Mar 2019 07:25:57 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:38328 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727154AbfCTLZ4 (ORCPT ); Wed, 20 Mar 2019 07:25:56 -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 C199A1650; Wed, 20 Mar 2019 04:25:55 -0700 (PDT) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C08D3F575; Wed, 20 Mar 2019 04:25:49 -0700 (PDT) Date: Wed, 20 Mar 2019 11:25:46 +0000 From: Catalin Marinas To: Andrew Morton Cc: Andrey Konovalov , Will Deacon , Mark Rutland , Robin Murphy , Kees Cook , Kate Stewart , Greg Kroah-Hartman , Ingo Molnar , "Kirill A . Shutemov" , Shuah Khan , Vincenzo Frascino , Eric Dumazet , "David S. Miller" , Alexei Starovoitov , Daniel Borkmann , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Arnaldo Carvalho de Melo , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Dmitry Vyukov , Kostya Serebryany , Evgeniy Stepanov , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Chintan Pandya , Luc Van Oostenryck , Dave Martin , Kevin Brodsky , Szabolcs Nagy , khalid.aziz@oracle.com Subject: Re: [PATCH v12 00/13] arm64: untag user pointers passed to the kernel Message-ID: <20190320112545.GB25040@arrakis.emea.arm.com> References: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> 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 Tue, Mar 19, 2019 at 11:32:12AM -0700, Andrew Morton wrote: > On Mon, 18 Mar 2019 18:17:32 +0100 Andrey Konovalov wrote: > > === Notes > > > > This patchset is meant to be merged together with "arm64 relaxed ABI" [3]. > > What does this mean, precisely? That neither series is useful without > the other? That either patchset will break things without the other? This series does the work of relaxing the ABI w.r.t. pointer syscall arguments for arm64 (while preserving backwards compatibility, we can't break this). Vincenzo's patches [1] document the ABI relaxation and introduce an AT_FLAG bit by which user space can check for the presence of such support. So I'd say [1] goes on top of this series. Once we agreed on the ABI definition, they should be posted as a single series. > Only a small fraction of these patches carry evidence of having been > reviewed. Fixable? That's fixable, though the discussions go back to last summer mostly at a higher level: are we sure these are the only places that need patching? The outcome of such discussions was a document clarifying which pointers user can tag and pass to the kernel based on the origins of the memory range (e.g. anonymous mmap()). I'd very much like to get input from the SPARC ADI guys on these series (cc'ing Khalid). While currently for arm64 that's just a software feature (the hardware one, MTE - memory tagging extensions, is coming later), the ADI has similar requirements regarding the user ABI. AFAICT from the SPARC example code, the user is not allowed to pass a tagged pointers (non-zero top byte) into the kernel. Feedback from the Google hwasan guys is that such approach is not practical for a generic deployment of this feature (e.g. automatic tagging of heap allocations). > Which maintainer tree would be appropriate for carrying these patches? Given that the arm64 changes are fairly minimal, the -mm tree works for me (once I reviewed/acked the patches and, ideally, get the SPARC people onboard with such approach). [1] https://lkml.org/lkml/2019/3/18/819 -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas at arm.com (Catalin Marinas) Date: Wed, 20 Mar 2019 11:25:46 +0000 Subject: [PATCH v12 00/13] arm64: untag user pointers passed to the kernel In-Reply-To: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> References: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> Message-ID: <20190320112545.GB25040@arrakis.emea.arm.com> On Tue, Mar 19, 2019 at 11:32:12AM -0700, Andrew Morton wrote: > On Mon, 18 Mar 2019 18:17:32 +0100 Andrey Konovalov wrote: > > === Notes > > > > This patchset is meant to be merged together with "arm64 relaxed ABI" [3]. > > What does this mean, precisely? That neither series is useful without > the other? That either patchset will break things without the other? This series does the work of relaxing the ABI w.r.t. pointer syscall arguments for arm64 (while preserving backwards compatibility, we can't break this). Vincenzo's patches [1] document the ABI relaxation and introduce an AT_FLAG bit by which user space can check for the presence of such support. So I'd say [1] goes on top of this series. Once we agreed on the ABI definition, they should be posted as a single series. > Only a small fraction of these patches carry evidence of having been > reviewed. Fixable? That's fixable, though the discussions go back to last summer mostly at a higher level: are we sure these are the only places that need patching? The outcome of such discussions was a document clarifying which pointers user can tag and pass to the kernel based on the origins of the memory range (e.g. anonymous mmap()). I'd very much like to get input from the SPARC ADI guys on these series (cc'ing Khalid). While currently for arm64 that's just a software feature (the hardware one, MTE - memory tagging extensions, is coming later), the ADI has similar requirements regarding the user ABI. AFAICT from the SPARC example code, the user is not allowed to pass a tagged pointers (non-zero top byte) into the kernel. Feedback from the Google hwasan guys is that such approach is not practical for a generic deployment of this feature (e.g. automatic tagging of heap allocations). > Which maintainer tree would be appropriate for carrying these patches? Given that the arm64 changes are fairly minimal, the -mm tree works for me (once I reviewed/acked the patches and, ideally, get the SPARC people onboard with such approach). [1] https://lkml.org/lkml/2019/3/18/819 -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Wed, 20 Mar 2019 11:25:46 +0000 Subject: [PATCH v12 00/13] arm64: untag user pointers passed to the kernel In-Reply-To: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> References: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> Message-ID: <20190320112545.GB25040@arrakis.emea.arm.com> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190320112546.aUNCozyOS_M5Tgmh9qezwRamAWtikHddwRVLXMICj0E@z> On Tue, Mar 19, 2019@11:32:12AM -0700, Andrew Morton wrote: > On Mon, 18 Mar 2019 18:17:32 +0100 Andrey Konovalov wrote: > > === Notes > > > > This patchset is meant to be merged together with "arm64 relaxed ABI" [3]. > > What does this mean, precisely? That neither series is useful without > the other? That either patchset will break things without the other? This series does the work of relaxing the ABI w.r.t. pointer syscall arguments for arm64 (while preserving backwards compatibility, we can't break this). Vincenzo's patches [1] document the ABI relaxation and introduce an AT_FLAG bit by which user space can check for the presence of such support. So I'd say [1] goes on top of this series. Once we agreed on the ABI definition, they should be posted as a single series. > Only a small fraction of these patches carry evidence of having been > reviewed. Fixable? That's fixable, though the discussions go back to last summer mostly at a higher level: are we sure these are the only places that need patching? The outcome of such discussions was a document clarifying which pointers user can tag and pass to the kernel based on the origins of the memory range (e.g. anonymous mmap()). I'd very much like to get input from the SPARC ADI guys on these series (cc'ing Khalid). While currently for arm64 that's just a software feature (the hardware one, MTE - memory tagging extensions, is coming later), the ADI has similar requirements regarding the user ABI. AFAICT from the SPARC example code, the user is not allowed to pass a tagged pointers (non-zero top byte) into the kernel. Feedback from the Google hwasan guys is that such approach is not practical for a generic deployment of this feature (e.g. automatic tagging of heap allocations). > Which maintainer tree would be appropriate for carrying these patches? Given that the arm64 changes are fairly minimal, the -mm tree works for me (once I reviewed/acked the patches and, ideally, get the SPARC people onboard with such approach). [1] https://lkml.org/lkml/2019/3/18/819 -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: [PATCH v12 00/13] arm64: untag user pointers passed to the kernel Date: Wed, 20 Mar 2019 11:25:46 +0000 Message-ID: <20190320112545.GB25040@arrakis.emea.arm.com> References: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> Sender: netdev-owner@vger.kernel.org To: Andrew Morton Cc: Andrey Konovalov , Will Deacon , Mark Rutland , Robin Murphy , Kees Cook , Kate Stewart , Greg Kroah-Hartman , Ingo Molnar , "Kirill A . Shutemov" , Shuah Khan , Vincenzo Frascino , Eric Dumazet , "David S. Miller" , Alexei Starovoitov , Daniel Borkmann , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Arnaldo Carvalho de Melo List-Id: linux-arch.vger.kernel.org On Tue, Mar 19, 2019 at 11:32:12AM -0700, Andrew Morton wrote: > On Mon, 18 Mar 2019 18:17:32 +0100 Andrey Konovalov wrote: > > === Notes > > > > This patchset is meant to be merged together with "arm64 relaxed ABI" [3]. > > What does this mean, precisely? That neither series is useful without > the other? That either patchset will break things without the other? This series does the work of relaxing the ABI w.r.t. pointer syscall arguments for arm64 (while preserving backwards compatibility, we can't break this). Vincenzo's patches [1] document the ABI relaxation and introduce an AT_FLAG bit by which user space can check for the presence of such support. So I'd say [1] goes on top of this series. Once we agreed on the ABI definition, they should be posted as a single series. > Only a small fraction of these patches carry evidence of having been > reviewed. Fixable? That's fixable, though the discussions go back to last summer mostly at a higher level: are we sure these are the only places that need patching? The outcome of such discussions was a document clarifying which pointers user can tag and pass to the kernel based on the origins of the memory range (e.g. anonymous mmap()). I'd very much like to get input from the SPARC ADI guys on these series (cc'ing Khalid). While currently for arm64 that's just a software feature (the hardware one, MTE - memory tagging extensions, is coming later), the ADI has similar requirements regarding the user ABI. AFAICT from the SPARC example code, the user is not allowed to pass a tagged pointers (non-zero top byte) into the kernel. Feedback from the Google hwasan guys is that such approach is not practical for a generic deployment of this feature (e.g. automatic tagging of heap allocations). > Which maintainer tree would be appropriate for carrying these patches? Given that the arm64 changes are fairly minimal, the -mm tree works for me (once I reviewed/acked the patches and, ideally, get the SPARC people onboard with such approach). [1] https://lkml.org/lkml/2019/3/18/819 -- 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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT 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 DD458C43381 for ; Wed, 20 Mar 2019 11:26:07 +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 A47FA2175B for ; Wed, 20 Mar 2019 11:26:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BKZNhlR5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A47FA2175B 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-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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hSndP2fkm6I6xah/BPahplLlwt4kxdrrFd7Q2NIHcew=; b=BKZNhlR5wtOmuH CH1ZX5IuloDuPUGBArpHoGafKIyYTmrFJjoCDnLEaGMixs4PRaLSkT3StqSviCH/5+UoemnOdYhep n2gnpRvKMXrbkQBdsQFlANeMAkxgJR57epO+E4W/xCJBcKUQJ2v492ydoywwC8Evzm8aDWUUG6H67 CYcg2f2v48tvnLo1dnqyrHOs8Oqgga+ptftnVBV7cCJHxu3Tm31TSzJI1Ke+SkfMoasgvimouFG2+ CtFu3YbQr5rX26moaexErWhL2iOLKgKrbjRyjsj15HCJBCYZSl6sjIKHvFuB6+VviZo40gILIJYfQ NsxSlFS25nq+ODYVceKw==; 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 1h6ZM7-0000X2-VW; Wed, 20 Mar 2019 11:25:59 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h6ZM4-0000WV-7h for linux-arm-kernel@lists.infradead.org; Wed, 20 Mar 2019 11:25:57 +0000 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 C199A1650; Wed, 20 Mar 2019 04:25:55 -0700 (PDT) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C08D3F575; Wed, 20 Mar 2019 04:25:49 -0700 (PDT) Date: Wed, 20 Mar 2019 11:25:46 +0000 From: Catalin Marinas To: Andrew Morton Subject: Re: [PATCH v12 00/13] arm64: untag user pointers passed to the kernel Message-ID: <20190320112545.GB25040@arrakis.emea.arm.com> References: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190319113212.ca1d56301112454dfb5a39ba@linux-foundation.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190320_042556_295302_A138B78A X-CRM114-Status: GOOD ( 14.46 ) 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 , Kate Stewart , linux-doc@vger.kernel.org, Peter Zijlstra , Will Deacon , Alexei Starovoitov , linux-mm@kvack.org, Eric Dumazet , linux-kselftest@vger.kernel.org, Chintan Pandya , Vincenzo Frascino , Shuah Khan , Ingo Molnar , linux-arch@vger.kernel.org, Jacob Bramley , Daniel Borkmann , Szabolcs Nagy , Ingo Molnar , Dmitry Vyukov , Ramana Radhakrishnan , Dave Martin , Evgeniy Stepanov , Kevin Brodsky , Kees Cook , Ruben Ayrapetyan , Andrey Konovalov , Lee Smith , Steven Rostedt , Arnaldo Carvalho de Melo , linux-arm-kernel@lists.infradead.org, Kostya Serebryany , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, khalid.aziz@oracle.com, Luc Van Oostenryck , netdev@vger.kernel.org, bpf@vger.kernel.org, Robin Murphy , "David S. Miller" , "Kirill A . Shutemov" 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 Tue, Mar 19, 2019 at 11:32:12AM -0700, Andrew Morton wrote: > On Mon, 18 Mar 2019 18:17:32 +0100 Andrey Konovalov wrote: > > === Notes > > > > This patchset is meant to be merged together with "arm64 relaxed ABI" [3]. > > What does this mean, precisely? That neither series is useful without > the other? That either patchset will break things without the other? This series does the work of relaxing the ABI w.r.t. pointer syscall arguments for arm64 (while preserving backwards compatibility, we can't break this). Vincenzo's patches [1] document the ABI relaxation and introduce an AT_FLAG bit by which user space can check for the presence of such support. So I'd say [1] goes on top of this series. Once we agreed on the ABI definition, they should be posted as a single series. > Only a small fraction of these patches carry evidence of having been > reviewed. Fixable? That's fixable, though the discussions go back to last summer mostly at a higher level: are we sure these are the only places that need patching? The outcome of such discussions was a document clarifying which pointers user can tag and pass to the kernel based on the origins of the memory range (e.g. anonymous mmap()). I'd very much like to get input from the SPARC ADI guys on these series (cc'ing Khalid). While currently for arm64 that's just a software feature (the hardware one, MTE - memory tagging extensions, is coming later), the ADI has similar requirements regarding the user ABI. AFAICT from the SPARC example code, the user is not allowed to pass a tagged pointers (non-zero top byte) into the kernel. Feedback from the Google hwasan guys is that such approach is not practical for a generic deployment of this feature (e.g. automatic tagging of heap allocations). > Which maintainer tree would be appropriate for carrying these patches? Given that the arm64 changes are fairly minimal, the -mm tree works for me (once I reviewed/acked the patches and, ideally, get the SPARC people onboard with such approach). [1] https://lkml.org/lkml/2019/3/18/819 -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel