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=-13.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 0286CC11F68 for ; Fri, 2 Jul 2021 05:27:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8B20B6141C for ; Fri, 2 Jul 2021 05:27:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B20B6141C 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 913BE8D02BD; Fri, 2 Jul 2021 01:27:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C3CD8D0001; Fri, 2 Jul 2021 01:27:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73D888D02BD; Fri, 2 Jul 2021 01:27:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) by kanga.kvack.org (Postfix) with ESMTP id 49CD28D0001 for ; Fri, 2 Jul 2021 01:27:45 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D2E4D22AA7 for ; Fri, 2 Jul 2021 05:27:44 +0000 (UTC) X-FDA: 78316515648.30.0441548 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf02.hostedemail.com (Postfix) with ESMTP id 8C4397001A08 for ; Fri, 2 Jul 2021 05:27:44 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id w17so11543841edd.10 for ; Thu, 01 Jul 2021 22:27:44 -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=l/CIfqGMmjYIsCzgr4AvzqUzXutEUTgHW7yZaII2nIc=; b=sMNxBgq6p8MYGYAzAdYHbTmZibqW4zuor+kGn8hkHguS73laLOeEzc/nKzBGZ/jY6V vmUpnTZqb8hDh+DVIkV5sXrURrJXRMXMZQWz1XL0hWPey5nCE537BjLl4USu/wdrxhLg sAxwU+9XDGZxVo6NAYFSkGKbBOr+KZZDXml/jMEayVacVgbKgOZ2QLKLW3aKY3Zx8RkR 6tmSGoryjw7lwbyTynz3bfKgFEWoo8U0IdRPACuFy0fSGpz4ZqqDVviku7f7eSYYNqTu or33zxc6BjrxQYJCwLtKGkijqVZBAp1O+WJA9Hai/knZ8ev6rjcS4BGDng2Ka3j5NR8K TvPg== 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=l/CIfqGMmjYIsCzgr4AvzqUzXutEUTgHW7yZaII2nIc=; b=WHd1Hx52dYyEBmw27SZWt06liUbBDML8wFGLZznoWkxbXkP7Zy4BPJ/RgArKJATwnL sOVY4qUvNLmk2TzA2BgimCKZexT2oCAqaUogR5kCPLDP7FdQWRMVsBX82LZa1J+yiohH VfXIypTgRdFIT2rtch0GNNaWAveoEeiaz2DJnc2zyJNg2B00tmO7jptEdMgiM7RgCk/u c+ed2ho4dNNconQERgZ/09ZCPz9JbztNThVXN3Y/Cq9JHNH3x04mqXEnvBokG946Dfox M2lCJd+cLjkpFZ2E5RXBcslqOT4ktTdZLu/71HRSL1VV4e2vq6S/ltGHuLIL3COgKUk7 aTIw== X-Gm-Message-State: AOAM5303KQKtRup368l7XG97oby/3SdNp5R+yqIP0fT36FRubGvbXY9a furrcxXShO0QhVw00rQJqbuErL+o0U1LfXXkJEKXCA== X-Google-Smtp-Source: ABdhPJzjfweoX/ejiqTW+J0NDOoQ3ivS/uibkApN9c3w09DsiOLqtcNArbaOUNc7jNRZTbVeNIcyjateo9yoVGWgWZM= X-Received: by 2002:a05:6402:312d:: with SMTP id dd13mr4489155edb.140.1625203663084; Thu, 01 Jul 2021 22:27:43 -0700 (PDT) MIME-Version: 1.0 References: <20210630232931.3779403-1-pcc@google.com> <20210701155148.GB12484@arm.com> In-Reply-To: From: Lokesh Gidra Date: Thu, 1 Jul 2021 22:27:31 -0700 Message-ID: Subject: Re: [PATCH v2] userfaultfd: preserve user-supplied address tag in struct uffd_msg To: Peter Collingbourne Cc: Catalin Marinas , Vincenzo Frascino , Dave Martin , Will Deacon , Andrew Morton , Andrea Arcangeli , Alistair Delva , William McVicker , Evgenii Stepanov , Mitch Phillips , Linux ARM , Linux Memory Management List , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8C4397001A08 X-Stat-Signature: two56nr5b1fq5hxd3b6fg6pwbofgwqiq Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=sMNxBgq6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=lokeshgidra@google.com X-HE-Tag: 1625203664-585034 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, Jul 1, 2021 at 10:50 AM Peter Collingbourne wrote: > > On Thu, Jul 1, 2021 at 8:51 AM Catalin Marinas wrote: > > > > Hi Peter, > > > > On Wed, Jun 30, 2021 at 04:29:31PM -0700, Peter Collingbourne wrote: > > > If a user program uses userfaultfd on ranges of heap memory, it may > > > end up passing a tagged pointer to the kernel in the range.start > > > field of the UFFDIO_REGISTER ioctl. This can happen when using an > > > MTE-capable allocator, or on Android if using the Tagged Pointers > > > feature for MTE readiness [1]. > > > > When we added the tagged addr ABI, we realised it's nearly impossible to > > sort out all ioctls, so we added a note to the documentation that any > > address other than pointer to user structures as arguments to ioctl() > > should be untagged. Arguably, userfaultfd is not a random device but if > > we place it in the same category as mmap/mremap/brk, those don't allow > > tagged pointers either. And we do expect some apps to break when they > > rely on malloc() to return untagged pointers. > > Okay, so arguably another approach would be to make userfaultfd > consistent with mmap/mremap/brk and let the UFFDIO_REGISTER fail if > given a tagged address. > This approach also seems reasonable. The problem, as things stand today, is that UFFDIO_REGISTER doesn't complain when a tagged pointer is used to register a memory range. But eventually the returned fault address in messages are untagged. If UFFDIO_REGISTER were to fail on passing a tagged pointer, then the userspace can address the issue. > > > When a fault subsequently occurs, the tag is stripped from the fault > > > address returned to the application in the fault.address field > > > of struct uffd_msg. However, from the application's perspective, > > > the tagged address *is* the memory address, so if the application > > > is unaware of memory tags, it may get confused by receiving an > > > address that is, from its point of view, outside of the bounds of the > > > allocation. We observed this behavior in the kselftest for userfaultfd > > > [2] but other applications could have the same problem. > > > > Just curious, what's generating the tagged pointers in the kselftest? Is > > it posix_memalign()? > > Yes, on Android that call goes into our allocator which returns the > tagged pointer. > > > > Fix this by remembering which tag was used to originally register the > > > userfaultfd and passing that tag back in fault.address. In a future > > > enhancement, we may want to pass back the original fault address, > > > but like SA_EXPOSE_TAGBITS, this should be guarded by a flag. > > > > I don't see exposing the tagged fault address vs making up a tag (from > > the original request) that different. I find the former cleaner from an > > ABI perspective, though it's a bit more intrusive to pass the tagged > > address via handle_mm_fault(). > > > > My preference is to fix this in user-space entirely, by explicit > > untagging of the malloc'ed pointer either before being passed to > > userfaultfd or when handling the userfaultfd message. How common is it > > for apps to register malloc'ed pointers with userfaultfd? I was hoping > > that's more of an (anonymous) mmap() play. I think it is very unlikely for someone to use malloc'ed pointers with userfaultfd. > > At least we haven't seen any apps do this so far, and the tagged > pointers feature has been in Android since last year's Android 11 > release. So maybe we can say this is uncommon enough that we can just > let userspace handle this. So we would do: > > 1. Forbid tagged pointers in the ioctl as mentioned above. > 2. Fix the kselftest (e.g. by untagging the pointer, or making it use > mmap). A fix would probably be needed here anyway because we noticed > that the test is later passing a tagged heap pointer to mremap (and > failing). The plan looks good to me. Using mmap (instead of posix_memalign) seems like a cleaner fix to the kselftest as compared to untagging the pointer everywhere. > > I'd be okay with this approach but I'd first like to hear from > Alistair and/or Lokesh since I think they favored the approach in my > patch. > > Peter