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=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,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 9AF6EC34031 for ; Tue, 18 Feb 2020 21:05:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4DA3F2070B for ; Tue, 18 Feb 2020 21:05:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vHbQzXXy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4DA3F2070B 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 EC5996B0005; Tue, 18 Feb 2020 16:05:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E750D6B0006; Tue, 18 Feb 2020 16:05:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8BD56B0007; Tue, 18 Feb 2020 16:05:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id C1DD96B0005 for ; Tue, 18 Feb 2020 16:05:28 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 886AC181AEF09 for ; Tue, 18 Feb 2020 21:05:28 +0000 (UTC) X-FDA: 76504478736.01.songs34_870bdc4f2e308 X-HE-Tag: songs34_870bdc4f2e308 X-Filterd-Recvd-Size: 6595 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Feb 2020 21:05:27 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id m25so23864748ioo.8 for ; Tue, 18 Feb 2020 13:05:27 -0800 (PST) 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=FLBYyhbEVK2WxYe7XRcltkQcdTtblO766M7V/ij5lvI=; b=vHbQzXXyoV+Y9zIOrjuFKrSsDtinOVGHe6Gcs+WggtyGJC4bR3luoPn/mUdOjXztHp jJtJyIgxuPvzG7KlmDZwWutFhZmKJoq5MJT6oniyPaRRmi2nOK6j/9F5ErAO1Lz6xciT 9SSXRHEEMto98eix6KMA7ibJDJf1ay8pWac7WWo1apLZp4Sf67HnBen+OQtrfb+W0Cby 2XmVqclfi65JK/bpt0MuFZ/Ui7UX4MGLTea1ziwhDDqtP9D8NWnsI6HAXhO5VaNKC0Qx jz6xGrp0XORRadoLS5jjL4fiwQM6ECUrNampu/I4Efj4AA8hq9PSJuvi+1mPK5Y+bUeY Zr1w== 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=FLBYyhbEVK2WxYe7XRcltkQcdTtblO766M7V/ij5lvI=; b=aBooOgAndApZZdFw1R2loBmBeM7DKeZsm55aEW4q6JYvKJiQQcphsIbE6mnqx1Ofta f+Aw+AQXzTiYrsHbpRDC2KwkxeMZsVQ2dGwmmYggrGTHZ7vVWL1npIpEdhpWrdrtw36T lnS6Ib0pUBArrjHoJmrbWVIUAtTUy25kfqLC9L+2Ap4t+uDeTYi4Yj/8yDcDT9ZjT9CW KGpiMza2ikO24UN+6taugotbTqr3+ZoBEuWB7b/Q5AFw/K5Bsoos+tGloYAQ/n4p1aZS 7zDdv5EB1JlJB28Ts2/BmFMf7nBPvyxqDgGISj7YZSRj4M/d7n3FyrGz5LLCyI68Tkzq tWPw== X-Gm-Message-State: APjAAAXYr9+1vHtGP57/Yb25RAOKZjOryvv0Mkx/uaiUm5TTelF+Q2/d xxbZILEDcqhFhyijBSeA/sLyXyQEzBEmkIuKuWTEZg== X-Google-Smtp-Source: APXvYqyIhJ2biuTZyCaoRFUVzvNeQwM4owFmTynxIZQ5l4t7g6zbJ1OKnQd4H+AaWIm2P2TPi9MpFTZ5VNcUxlWjWaU= X-Received: by 2002:a02:c85b:: with SMTP id r27mr17877406jao.57.1582059926803; Tue, 18 Feb 2020 13:05:26 -0800 (PST) MIME-Version: 1.0 References: <20200218122310.72710-1-catalin.marinas@arm.com> <20200218123426.GA19776@willie-the-truck> In-Reply-To: From: Evgenii Stepanov Date: Tue, 18 Feb 2020 13:05:14 -0800 Message-ID: Subject: Re: [PATCH] mm: Avoid creating virtual address aliases in brk()/mmap()/mremap() To: Andrey Konovalov Cc: Catalin Marinas , Linux Memory Management List , Linux ARM , Szabolcs Nagy , Andrew Morton , Florian Weimer , Victor Stinner , Will Deacon 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 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? 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. > > > > > > > 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