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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 CB682C2D0E4 for ; Mon, 23 Nov 2020 15:28:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3FD9920719 for ; Mon, 23 Nov 2020 15:28:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="NQZmlnHO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FD9920719 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8EECF6B00A4; Mon, 23 Nov 2020 10:28:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 84E6A6B00A6; Mon, 23 Nov 2020 10:28:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A0106B00A7; Mon, 23 Nov 2020 10:28:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 309E36B00A4 for ; Mon, 23 Nov 2020 10:28:42 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B8A523637 for ; Mon, 23 Nov 2020 15:28:41 +0000 (UTC) X-FDA: 77516065242.20.cub03_0e0b9ae27366 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 90E72180C07AF for ; Mon, 23 Nov 2020 15:28:41 +0000 (UTC) X-HE-Tag: cub03_0e0b9ae27366 X-Filterd-Recvd-Size: 5688 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Mon, 23 Nov 2020 15:28:40 +0000 (UTC) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7997E21D40 for ; Mon, 23 Nov 2020 15:28:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606145319; bh=brIo8Xk+cpg0T6s0IpQa46LwLk4mVPqFLLwG7n90WGU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NQZmlnHOZiaM7ybcSwWzusNQy1pIzNLZhcrN2FxiI5VI77KySCK6gXqHvbc4GeRrP YSCkK4YhIEwNNqxjz0cYUoQdSP0hpYXSadkkeXAKDctf0PJDujPReGf2go++Ttg8qu rA7cZa4607GuG26Tp3k6RmHtRqCHyFe1H0bZsEVY= Received: by mail-wm1-f49.google.com with SMTP id a65so17631900wme.1 for ; Mon, 23 Nov 2020 07:28:39 -0800 (PST) X-Gm-Message-State: AOAM533c8k0LpwijtuETmtb/NDH7KrboMMvFlm+PPjFv+j5Uy1TZ/g0t ApFqlyMt6ukK/k3HPZr0gYKCqv0W5JJBhZa7llPwRA== X-Google-Smtp-Source: ABdhPJzEhjqlImvathm/jOwbcq17IbRsly+UVqGOW3wf5Zw5ZyQfK4pkOn8rE+oX1x7EWd6oQaZF3bxA3Eqxcxk30tI= X-Received: by 2002:a1c:e0c3:: with SMTP id x186mr24542133wmg.21.1606145315717; Mon, 23 Nov 2020 07:28:35 -0800 (PST) MIME-Version: 1.0 References: <20201123095432.5860-1-rppt@kernel.org> In-Reply-To: <20201123095432.5860-1-rppt@kernel.org> From: Andy Lutomirski Date: Mon, 23 Nov 2020 07:28:22 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v10 0/9] mm: introduce memfd_secret system call to create "secret" memory areas To: Mike Rapoport Cc: Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , Linux API , linux-arch , linux-arm-kernel , Linux FS Devel , Linux-MM , LKML , "open list:KERNEL SELFTEST FRAMEWORK" , linux-nvdimm , linux-riscv@lists.infradead.org, X86 ML 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 Mon, Nov 23, 2020 at 1:54 AM Mike Rapoport wrote: > > From: Mike Rapoport > > Hi, > > This is an implementation of "secret" mappings backed by a file descriptor. > > The file descriptor backing secret memory mappings is created using a > dedicated memfd_secret system call The desired protection mode for the > memory is configured using flags parameter of the system call. The mmap() > of the file descriptor created with memfd_secret() will create a "secret" > memory mapping. The pages in that mapping will be marked as not present in > the direct map and will have desired protection bits set in the user page > table. For instance, current implementation allows uncached mappings. I'm still not ready to ACK uncached mappings on x86. I'm fine with the concept of allowing privileged users to create UC memory on x86 for testing and experimentation, but it's a big can of worms in general. The issues that immediately come to mind are: - Performance and DoS potential. UC will have bizarre, architecture- and platform-dependent performance characteristics. For all I know, even the access semantics might be architecture dependent. I'm not convinced it's possible to write portable code in C using the uncached feature. I'm also concerned that certain operation (unaligned locks, for example, and possibly any locked access) will trigger bus locks on x86, which, depending on CPU and kernel config will either DoS all other CPUs or send signals. (Or cause the hypervisor to terminate or otherwise penalize the the VM, which would be nasty.) - Correctness. I have reports that different x86 hypervisors do different things with UC mappings, including treating them as regular WB mappings. So the memory type you get out when you ask for "uncached" might not actually be uncached. UC is really an MMIO feature, not a "protect my data" feature. Abusing it to protect data is certainly interesting, but I'm far from convinced that it's wise. I'm especially unconvinced that monkey-patching a program to use uncached memory when it expects regular malloced memory is a reasonable thing to do.