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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 8CE11C34047 for ; Wed, 19 Feb 2020 10:39:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4C42424671 for ; Wed, 19 Feb 2020 10:39:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="vKhrxTz7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C42424671 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 C64A56B0007; Wed, 19 Feb 2020 05:39:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C13AD6B0008; Wed, 19 Feb 2020 05:39:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2A986B000A; Wed, 19 Feb 2020 05:39:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 9C5C56B0007 for ; Wed, 19 Feb 2020 05:39:34 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 24C1E180AD815 for ; Wed, 19 Feb 2020 10:39:34 +0000 (UTC) X-FDA: 76506530268.15.slave31_709f4e5a1dd06 X-HE-Tag: slave31_709f4e5a1dd06 X-Filterd-Recvd-Size: 3996 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Feb 2020 10:39:33 +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 92F0E2465D; Wed, 19 Feb 2020 10:39:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582108773; bh=t6EucisUj3k9GKUi9HzDCHyuy6JHeDY4sFIA89ws9Zs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vKhrxTz7kLkP5Q3WCfvximPTS9d76j8T5d1IVUcaVRRdanVzi23IvRxv/oiDR3fsD FbgQUhB42zAKZNiz4BljbYQwUf9BRfFw762rCPVGjsXuHPLWGLF+nAPuWJAo54EiPl aNal4xwK6v1FkaX9bNp72NWnxU/3ocf4YTd8bSxE= Date: Wed, 19 Feb 2020 10:39:28 +0000 From: Will Deacon To: Evgenii Stepanov Cc: Andrey Konovalov , Catalin Marinas , Linux Memory Management List , Linux ARM , Szabolcs Nagy , Andrew Morton , Florian Weimer , Victor Stinner Subject: Re: [PATCH] mm: Avoid creating virtual address aliases in brk()/mmap()/mremap() Message-ID: <20200219103927.GB16824@willie-the-truck> References: <20200218122310.72710-1-catalin.marinas@arm.com> <20200218123426.GA19776@willie-the-truck> 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) 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 01:05:14PM -0800, Evgenii Stepanov wrote: > On Tue, Feb 18, 2020 at 5:07 AM Andrey Konovalov wrote: > > > > On Tue, Feb 18, 2020 at 1:34 PM Will Deacon wrote: > > > > > > 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. > > > > Evgenii, do you know if this will cause any issues for HWASAN? > > Is it possible to preserve the untagging behavior when a process has > opted in TBI? It's /possible/, but without a concrete need I'm not keen to special case mmap() like this. "Avoid aliasing user addresses" is an enforceable rule across all system calls and is easily documented as such, so I'd prefer to start from that position and only add exceptions where they are really needed. That clearly doesn't preclude adding them later on with an extension to the current prctl() controls. > I have not seen an actual issue with a tagged pointer in mmap yet > (I've seen two with mprotect, but not mmap or sbrk), so we should be > fine either way. Right, and we're leaving mprotect() and madvise() as they were. Will