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=-18.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, 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 69B80C388F9 for ; Fri, 20 Nov 2020 03:08:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B207022256 for ; Fri, 20 Nov 2020 03:08:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qa7gmGz7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B207022256 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 CF16F6B0036; Thu, 19 Nov 2020 22:08:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CA2796B005C; Thu, 19 Nov 2020 22:08:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8F6C6B005D; Thu, 19 Nov 2020 22:08:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by kanga.kvack.org (Postfix) with ESMTP id 80AB56B0036 for ; Thu, 19 Nov 2020 22:08:54 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1114D824999B for ; Fri, 20 Nov 2020 03:08:54 +0000 (UTC) X-FDA: 77503314588.21.juice14_340bd6527348 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id E4EBD18018143 for ; Fri, 20 Nov 2020 03:08:53 +0000 (UTC) X-HE-Tag: juice14_340bd6527348 X-Filterd-Recvd-Size: 6947 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Nov 2020 03:08:53 +0000 (UTC) Received: by mail-ed1-f68.google.com with SMTP id q16so8022902edv.10 for ; Thu, 19 Nov 2020 19:08:53 -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=YtXOZvjpEpFV/ldFOanGBLjptcLyTt0EXS/OYP43evM=; b=qa7gmGz757OlSDFTjsk05inFC6M0LF1M3mE19DcQpwXzKoWt19gd0JQuk1LLbXZ3BR LCDoAOGXiXtnvdWeoHirvsUrxoW7itKGg+49YbWkwr9cTDviYnxcBPm07I0W7v6Pwpfp 58M7Y+NavVaSmUUAgOSlYS5MYKiGyZdIQKDtx9YkKq54SY5qSzjFymOVbIdbmVpH4LqI Dx5KOMWYoq4FVSUMODPpeHTwinvQ4bNBxXy8sVYUTgVzvZPWvbLznSMfKQ/e35FVxiz/ b1OZqoe5BF+Q9d+YPQp5lcqWxLxRMw/MUb+HzcwEVfZzFYJXpQK6NX2j2/6/HAYyz7Zg ZiPQ== 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=YtXOZvjpEpFV/ldFOanGBLjptcLyTt0EXS/OYP43evM=; b=oVQOy0CVziWU39lKqbN0tZkNWpTHxv7Ce2bNkeSiHMq+20QnDWcIr2mnOcVYtzLUSR NDJnhbz35NgNsAd4nQZfm6xsMDsmpsNluCZGk6sbrbIwKgSycUrKK2aT2XqGqrj0q5Tj h97Zh28dMGFD3D8vfxlCrfFRWrdMIZ++rMH8xhffHkRtrlkw4kdCZVF5oVzVXgE8g+sC IUsED9sifXNp04Jd1CFDm9I14jB8gH3GKzNqyk3qpOgeSbvMrNI2QzC7h4oxAN+OXNZy IyhAbGgOIqCX2+0TKStqogt58HF+xqPglIrj1M52Q8tiA1rGvA4zBGdtNRqPaG9QhHk6 wMaw== X-Gm-Message-State: AOAM533FrHLJ1K6njch5HXsVb5ergYK+BUpn/daf3Xor2Q47bgH/pAaV 6RUbVKTtxtYjShPRJkKPXAbcyxEqkW8LOQqnqS1ZlA== X-Google-Smtp-Source: ABdhPJz7RJjzL+hufqMNJi6uAMHBGxu2W0f9OprYCaMoFixITN8wKxcO/vk1C+Dq41gKH/gCCQUQeRDxgtqHoSzRzFE= X-Received: by 2002:aa7:d34e:: with SMTP id m14mr32575884edr.42.1605841731812; Thu, 19 Nov 2020 19:08:51 -0800 (PST) MIME-Version: 1.0 References: <20201120030411.2690816-1-lokeshgidra@google.com> In-Reply-To: <20201120030411.2690816-1-lokeshgidra@google.com> From: Lokesh Gidra Date: Thu, 19 Nov 2020 19:08:39 -0800 Message-ID: Subject: Re: [PATCH v6 0/2] Control over userfaultfd kernel-fault handling To: Kees Cook , Jonathan Corbet , Peter Xu , Andrea Arcangeli , Sebastian Andrzej Siewior , Andrew Morton Cc: Alexander Viro , Stephen Smalley , Eric Biggers , Daniel Colascione , "Joel Fernandes (Google)" , Linux FS Devel , linux-kernel , linux-doc@vger.kernel.org, Kalesh Singh , Calin Juravle , Suren Baghdasaryan , Jeffrey Vander Stoep , "Cc: Android Kernel" , Mike Rapoport , Shaohua Li , Jerome Glisse , Mauro Carvalho Chehab , Johannes Weiner , Mel Gorman , Nitin Gupta , Vlastimil Babka , Iurii Zaikin , Luis Chamberlain , "open list:MEMORY MANAGEMENT" 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 Thu, Nov 19, 2020 at 7:04 PM Lokesh Gidra wrote: > > This patch series is split from [1]. The other series enables SELinux > support for userfaultfd file descriptors so that its creation and > movement can be controlled. > > It has been demonstrated on various occasions that suspending kernel > code execution for an arbitrary amount of time at any access to > userspace memory (copy_from_user()/copy_to_user()/...) can be exploited > to change the intended behavior of the kernel. For instance, handling > page faults in kernel-mode using userfaultfd has been exploited in [2, 3]. > Likewise, FUSE, which is similar to userfaultfd in this respect, has been > exploited in [4, 5] for similar outcome. > > This small patch series adds a new flag to userfaultfd(2) that allows > callers to give up the ability to handle kernel-mode faults with the > resulting UFFD file object. It then adds a 'user-mode only' option to > the unprivileged_userfaultfd sysctl knob to require unprivileged > callers to use this new flag. > > The purpose of this new interface is to decrease the chance of an > unprivileged userfaultfd user taking advantage of userfaultfd to > enhance security vulnerabilities by lengthening the race window in > kernel code. > > [1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/ > [2] https://duasynt.com/blog/linux-kernel-heap-spray > [3] https://duasynt.com/blog/cve-2016-6187-heap-off-by-one-exploit > [4] https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html > [5] https://bugs.chromium.org/p/project-zero/issues/detail?id=808 > > Changes since v5: > > - Added printk_once when unprivileged_userfaultfd is set to 0 and > userfaultfd syscall is called without UFFD_USER_MODE_ONLY in the > absence of CAP_SYS_PTRACE capability. > > Changes since v4: > > - Added warning when bailing out from handling kernel fault. > > Changes since v3: > > - Modified the meaning of value '0' of unprivileged_userfaultfd > sysctl knob. Setting this knob to '0' now allows unprivileged users > to use userfaultfd, but can handle page faults in user-mode only. > - The default value of unprivileged_userfaultfd sysctl knob is changed > to '0'. > > Changes since v2: > > - Removed 'uffd_flags' and directly used 'UFFD_USER_MODE_ONLY' in > userfaultfd(). > > Changes since v1: > > - Added external references to the threats from allowing unprivileged > users to handle page faults from kernel-mode. > - Removed the new sysctl knob restricting handling of page > faults from kernel-mode, and added an option for the same > in the existing 'unprivileged_userfaultfd' knob. > > Lokesh Gidra (2): > Add UFFD_USER_MODE_ONLY > Add user-mode only option to unprivileged_userfaultfd sysctl knob > > Documentation/admin-guide/sysctl/vm.rst | 15 ++++++++++----- > fs/userfaultfd.c | 20 +++++++++++++++++--- > include/uapi/linux/userfaultfd.h | 9 +++++++++ > 3 files changed, 36 insertions(+), 8 deletions(-) > > -- > 2.29.0.rc1.297.gfa9743e501-goog > Adding linux-mm@kvack.org mailing list.