Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1675034ybh; Mon, 20 Jul 2020 04:33:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyM5ikHbwYeuunfBzFW+u5goDPT5i+GGSQPC27uYHyvvf/uVEemuLtUpahP9Yb46pLzmyYM X-Received: by 2002:a05:6402:a43:: with SMTP id bt3mr20567480edb.332.1595244783427; Mon, 20 Jul 2020 04:33:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595244783; cv=none; d=google.com; s=arc-20160816; b=skRBHtcQh3iKK8VMRHluWFG4HsQefl6ZL9T/cAdG9roZoQy5Mp0iwQ2HSoGrBrF3lq LoXDfyJGQ6Eg4ixt8I7cCUespb+NNK1/Gebg3+kJGpM/uq4Y/PbYWHECdArWm+8mJaxu HDEuNgvEm2Gp8xU44ew3oxEJs9qNgpZlnc4OvOTvJsndcJMPAzOJaxghwLYiqLwu/zH0 087WoiLuKUc2QZ3wgEX2IO5IzJfMwIyOU9oN/zscLCCIo+0rtDTj03Wp13vnopCfz2C5 3+Alr6GSc37Jk6HkuXqswsJDv46gz8RSw7ZpTQVi7VsoJPFyte0sCqD2XI+LcQKw7y18 u6PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=nEsAYgV6dUvTuPfnbYzgaFQz/Q1MvqDJq1dtCPVdYDw=; b=urly5hEnt6pDJk1bvdEo4wcpZYxUqlAbwaLDbRpWgCL6sA2ypw+NzeIJNIwARAsG5d fz/Q2DZj1h62kny/3Mj8AMJowmTJq1vmfa7eAOkOkCGnXti0Hc4t27MqGsZpGqw+gXau aZLZEWmtQT9wBY9H39uqZ53z3Vb6XnQX7DVqwKt6XoHSTR8BfuynjxRxDoM2s5XnvWNB kCBDiGvU7vCumXpmSsV+j0FLik70XWCqOlPKMlvPsD+JFXpTX32EzHikGa9f0k6JRrdm d3fj+zVDyXoHD0a1BO+5Bs/hF0eQ9iLBbZVcHKCiIaovZPFkV4ccMVVky4CyJmV7pAF4 HiuA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dd11si9863180edb.79.2020.07.20.04.32.40; Mon, 20 Jul 2020 04:33:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728588AbgGTLae (ORCPT + 99 others); Mon, 20 Jul 2020 07:30:34 -0400 Received: from mout.kundenserver.de ([217.72.192.74]:35313 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728058AbgGTLad (ORCPT ); Mon, 20 Jul 2020 07:30:33 -0400 Received: from mail-qk1-f170.google.com ([209.85.222.170]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MRSdf-1k9Ok72cqr-00NTol; Mon, 20 Jul 2020 13:30:30 +0200 Received: by mail-qk1-f170.google.com with SMTP id 80so14817204qko.7; Mon, 20 Jul 2020 04:30:30 -0700 (PDT) X-Gm-Message-State: AOAM533b9YzZWWSK2VaipD1h2AnkEirKKrzZLtfVzSdHYYCMguVcfIZV XQGqfFuBGbZHRM6c7FcqDgXWQoYgJwKsrLkTPDg= X-Received: by 2002:a05:620a:1654:: with SMTP id c20mr20996310qko.138.1595244629225; Mon, 20 Jul 2020 04:30:29 -0700 (PDT) MIME-Version: 1.0 References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> In-Reply-To: <20200720092435.17469-4-rppt@kernel.org> From: Arnd Bergmann Date: Mon, 20 Jul 2020 13:30:13 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas To: Mike Rapoport Cc: "linux-kernel@vger.kernel.org" , Alexander Viro , Andrew Morton , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Idan Yaniv , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mike Rapoport , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Thomas Gleixner , Tycho Andersen , Will Deacon , Linux API , linux-arch , Linux ARM , Linux FS-devel Mailing List , Linux-MM , linux-nvdimm@lists.01.org, linux-riscv , "the arch/x86 maintainers" , linaro-mm-sig@lists.linaro.org, Sumit Semwal Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:TfMVKI8Xwwil9I21P8OmonrH2jkQ8LQLt3AUMzzKE3uFso+l/Ie dWFOAW34L1oerzNOfgd6/x4mRQaYHRpbfB5vnLm9Jc5BD+P3vDLbFxj9ZPunj8IhEkHh8yT NpZP+/Dh2Vtk2D8LkfOIR3jZGQmfRIAwPyWb4mamJnPb00tX7n5moKVad9lP6bc2Sxsn/Zv uJkF+a1KD/24lXRqsz0BQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:by+CjfWV5wU=:5W1HSFIYkjF1Xls7nDjsrF zPOIOYqc6MG1WsW/TJkgz8B543REI1efhIjAZTCl8hl54UAoxo0qtrlUXi27OkDb06rCki8SE PrH9QehiykmvXgC0CWGnP5UhgZJq88hRye+jhN+/c4q6JdMdLDdsfAKBZkbVJqHv4euRSHcCB pMRldOesaZG68Ri01KstRYq+uO0qvC3cGFOgL7jE62JZwc1MZMVCNAAruGz6LyGDGZ5ffjlZu cI+6BSG4/1Tuo0qd90tDZdQdLzdqbGbGvm9dRT4V42fJfmB1QaHt1jjrtDzWYc82XBKzC90WN strBEtRNEN6rijs14n8XSpcfCoZBjCQdcXBvomqj2rbiTUJNpf7nD8WbtR0ijUN63PwOdr+qw NLdAhi5bJWI16DWIfaabkdoK1O47W3P9Z0fQuFNw8TG0D9XKAPvrJGrP7Sypuly1/UPgiWrf3 34/vTl1bkVSzZWfMi+J3YVwdec5oJ8AR58c+F69IBoBz8htFMSXfAjMQVBigZMgnVGkXqoYRy 5xQe5sbB1GaaXEVgxVpZsTXlf2p/JuU3PZG2+ZpjCUWVrT1yVUGU6E+inuYNt5UarVcidxnS/ Kv/7GjAApsC1rmKxa0RGN1uWHd/b2I5CsaMyfilr3Up/Hib6etrERmTZUH/t6+UHQtYjpBL6G HY7LqdFXjkXb2qPUm6BpCbyuWeqlJ2Y3ULn6o0TF/gOHv3nkqIL4IV2yvc5vmyrYGn9ISS2yy 0ibKXIMN7KdKRllILtPYah2wamWjdw25ghSi3b6Yd1/uJZYzfL0ZQq1Zyjqog/Xyb0YnhthyD ptQoabXcOne1rys3kOv80NTwZZzp2R+MtSQTJNil9zt1ZmbW0wRejytP8kBuM1SOJcnew6y/G x/k/iNo+p9hCG/1dUA/DgqUBr9JWlPUNRqhi+Pijmj1sGzbXgl/L53e72cY7EfOjjzKDoVTBH ISVSBtTHqZruPQS8vu9AvidlRNnn7ts46+P9XBMolGWhQBYjbhJQC Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport wrote: > > From: Mike Rapoport > > Introduce "secretmemfd" system call with the ability to create memory areas > visible only in the context of the owning process and not mapped not only > to other processes but in the kernel page tables as well. > > The user will create a file descriptor using the secretmemfd system call > where flags supplied as a parameter to this system call will define the > desired protection mode for the memory associated with that file > descriptor. Currently there are two protection modes: > > * exclusive - the memory area is unmapped from the kernel direct map and it > is present only in the page tables of the owning mm. > * uncached - the memory area is present only in the page tables of the > owning mm and it is mapped there as uncached. > > For instance, the following example will create an uncached mapping (error > handling is omitted): > > fd = secretmemfd(SECRETMEM_UNCACHED); > ftruncate(fd, MAP_SIZE); > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, > fd, 0); > > Signed-off-by: Mike Rapoport I wonder if this should be more closely related to dmabuf file descriptors, which are already used for a similar purpose: sharing access to secret memory areas that are not visible to the OS but can be shared with hardware through device drivers that can import a dmabuf file descriptor. Arnd