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.3 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,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 4C159C4707E for ; Fri, 21 May 2021 22:41:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BBFD861353 for ; Fri, 21 May 2021 22:41:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BBFD861353 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 A86738E0076; Fri, 21 May 2021 18:41:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2C738E0072; Fri, 21 May 2021 18:41:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C7718E0076; Fri, 21 May 2021 18:41:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0082.hostedemail.com [216.40.44.82]) by kanga.kvack.org (Postfix) with ESMTP id 1E52F8E0072 for ; Fri, 21 May 2021 18:41:45 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B4F496D97 for ; Fri, 21 May 2021 22:41:44 +0000 (UTC) X-FDA: 78166711728.20.0FF23D0 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by imf13.hostedemail.com (Postfix) with ESMTP id 3BA2BE000803 for ; Fri, 21 May 2021 22:41:41 +0000 (UTC) Received: by mail-io1-f48.google.com with SMTP id z24so21695650ioi.3 for ; Fri, 21 May 2021 15:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=ZmYWfdKfyCPvHmUvMMYMOqW4s0b2D2mreMHld29eEew=; b=fpmrZL03jPMwPP2G6TFLBKAPmJ/ar8CFRro1F2AcsB0CHft+UQ6DOZVhZflNBVneJG iODtmu71aQTvyMihJnoFdMYS3rDp9VKhN5eCyco+uI109vm6W26aiQ4fsZrFRf8VKQrD /KXn9RQ5uCO0NS8p6Bfq0ioCzwInp4x8Adni9GM1xllk69kNBL2BLhzJLkxvqMcYjhPK a78NtKFTrQ/+k+JSVGE8HzREg4h2x3i6sI4F+w3GPaRPqCoFv8G4+4dDIQWBrc9rgwC3 o0p5aaGT4/9pu1PB8uGwRoPquK5jLazxMS1LUlxqktxKnESZX6qBbQPgcuvEWp4uAHhX Zfrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ZmYWfdKfyCPvHmUvMMYMOqW4s0b2D2mreMHld29eEew=; b=H3sg+ENybS1C2HWE6j9RsAj4QjAW8A64mFkyKybqNkIikCZjB5etS1Bf5mUhB7T8xR 8wJymruo5UpIc1/A8E/7YXlBR3BwKdN+Gs0SqLXypwAFRrcCvAh6aTCe9fWbrY5paboS JoIxxBmU+vbGz4Z7MHgYWbNYK2wfgqxcEHGrO5nYYHsAJJkD78eXs9e3ER4A6fT/hlWe U8+pzZ2qNgrolKWGFvM3nXVhZXGRKfQBCAC6xpKJe/cS9T5OaRKsLwQO6I54aapYDlXf RFDvyd7QST7eJpxwgDIrCU7ndf1AzQoPBOB3UtOt8RvPcjUdQ6Sv51/Qr/huryss9OMA EIjg== X-Gm-Message-State: AOAM533QUXc2zhX+O5R011dF7+O/6l40KaOCB+UJPZmlTz+mWknGAW6y oqPMPj88D6EiYXaVD5uUlBexJbwz/sFmT6Btldix3A== X-Google-Smtp-Source: ABdhPJz5vmbAKYTQ9EnFHHydH727JpCIcNdl9hgqYHBKqP90d3+9XGm2e5ZCqcR1VC+wKjiKpuVipkp6ODsylOHDsys= X-Received: by 2002:a05:6638:124b:: with SMTP id o11mr7575839jas.4.1621636903864; Fri, 21 May 2021 15:41:43 -0700 (PDT) MIME-Version: 1.0 From: Axel Rasmussen Date: Fri, 21 May 2021 15:41:07 -0700 Message-ID: Subject: Adding a new capability for userfaultfd? To: Peter Xu , Andrea Arcangeli Cc: Linux MM , James Houghton , Lokesh Gidra Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=fpmrZL03; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=axelrasmussen@google.com X-Stat-Signature: 3xomih19ez895q1qm1wpj9xafaeo4ddp X-Rspamd-Queue-Id: 3BA2BE000803 X-Rspamd-Server: rspam02 X-HE-Tag: 1621636901-46995 X-Bogosity: Ham, tests=bogofilter, spamicity=0.002699, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi all, Somewhat recently, this series [1] added UFFD_USER_MODE_ONLY. The idea is, letting userspace intercept kernel faults opens a potential attack surface, so it's better to restrict this by default. However, consider the use case of live migration. We have some userspace process on the migration target, which needs to handle kernel faults. With this series, we have two options: 1. Grant this userspace process more privileges - CAP_SYS_PTRACE, run as root, etc. 2. Disable the UFFD_USER_MODE_ONLY restriction, via vm.userfault. We would prefer not to do (2), as this opens up the attack surface [1] was originally trying to address. We'd also prefer not to do (1), because it sort of grants the live migration handler the permissions it needs, *plus a lot more*. It's sort of not fine grained enough. So, what are your thoughts on adding a new CAP_USERFAULTFD, as a more fine grained way to grant this specific permission? It seems like there is some precedent for this - take CAP_CHECKPOINT_RESTORE, for example. If this passes a quick sanity check, I can send a series which does this for review. Thanks! [1]: https://lore.kernel.org/patchwork/cover/1342060/