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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 868EFC34026 for ; Tue, 18 Feb 2020 12:34:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 27AD221D56 for ; Tue, 18 Feb 2020 12:34:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="A4LEQwuZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27AD221D56 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A2A406B0003; Tue, 18 Feb 2020 07:34:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B3926B0006; Tue, 18 Feb 2020 07:34:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A2776B0007; Tue, 18 Feb 2020 07:34:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0118.hostedemail.com [216.40.44.118]) by kanga.kvack.org (Postfix) with ESMTP id 6DC4B6B0003 for ; Tue, 18 Feb 2020 07:34:33 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 22DDB180AD815 for ; Tue, 18 Feb 2020 12:34:33 +0000 (UTC) X-FDA: 76503191226.23.woman20_27af9141c0f14 X-HE-Tag: woman20_27af9141c0f14 X-Filterd-Recvd-Size: 4530 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Feb 2020 12:34:32 +0000 (UTC) Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 593D22176D; Tue, 18 Feb 2020 12:34:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582029271; bh=KDL23XVFLeKVTxiEhY0FXtoYd2oFq3CDaL6YbxA1Xsg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A4LEQwuZfnWVTSl9AAd5GsxoXAM1lP3NLtvaNSsSoy/AUziCAjMIHPEMEK6/ZicNQ YaJSiWG/44CKoYX39oa22bnryRq3BGRTO717zKyRKkfPQ3Q40Er4PNvvimg/0cBDDf yuqdgeGQ3Rc9AnoKeq9n3mCIKes2CH0YXW+E0grI= Date: Tue, 18 Feb 2020 12:34:26 +0000 From: Will Deacon To: Catalin Marinas Cc: linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Szabolcs Nagy , Andrey Konovalov , Andrew Morton , Florian Weimer , Victor Stinner Subject: Re: [PATCH] mm: Avoid creating virtual address aliases in brk()/mmap()/mremap() Message-ID: <20200218123426.GA19776@willie-the-truck> References: <20200218122310.72710-1-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200218122310.72710-1-catalin.marinas@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Tue, Feb 18, 2020 at 12:23:10PM +0000, Catalin Marinas wrote: > Currently the arm64 kernel ignores the top address byte passed to brk(), > mmap() and mremap(). When the user is not aware of the 56-bit address > limit or relies on the kernel to return an error, untagging such > pointers has the potential to create address aliases in user-space. > Passing a tagged address to munmap(), madvise() is permitted since the > tagged pointer is expected to be inside an existing mapping. Might be worth mentioning that this is causing real issues for existing userspace: https://bugzilla.redhat.com/show_bug.cgi?id=1797052 and so should be merged as a fix. > Remove untagging in the above functions by partially reverting commit > ce18d171cb73 ("mm: untag user pointers in mmap/munmap/mremap/brk"). In > addition, update the arm64 tagged-address-abi.rst document accordingly. > > Fixes: ce18d171cb73 ("mm: untag user pointers in mmap/munmap/mremap/brk") > Cc: # 5.4.x- > Cc: Andrey Konovalov > Cc: Will Deacon > Cc: Andrew Morton > Cc: Florian Weimer > Reported-by: Victor Stinner > Signed-off-by: Catalin Marinas > --- > Documentation/arm64/tagged-address-abi.rst | 7 +++++-- > mm/mmap.c | 4 ---- > mm/mremap.c | 1 - > 3 files changed, 5 insertions(+), 7 deletions(-) > > diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst > index d4a85d535bf9..1771a8b5712e 100644 > --- a/Documentation/arm64/tagged-address-abi.rst > +++ b/Documentation/arm64/tagged-address-abi.rst > @@ -44,8 +44,11 @@ The AArch64 Tagged Address ABI has two stages of relaxation depending > how the user addresses are used by the kernel: > > 1. User addresses not accessed by the kernel but used for address space > - management (e.g. ``mmap()``, ``mprotect()``, ``madvise()``). The use > - of valid tagged pointers in this context is always allowed. > + management (e.g. ``mprotect()``, ``madvise()``). The use of valid > + tagged pointers in this context is allowed with the exception of > + ``brk()``, ``mmap()`` and the ``new_address`` argument to > + ``mremap()`` as these have the potential of aliasing with existing > + user addresses. Given that we're backporting this to stable kernels, perhaps it's worth a note here along the lines of: NOTE: This behaviour changed in v5.6 and so some earlier kernels may incorrectly accept valid tagged pointers for these system calls. With that: Acked-by: Will Deacon Happy to take this as an arm64 fix for 5.6, unless Andrew would prefer to route it via his tree. Will