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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 4D62CCA9EC4 for ; Tue, 29 Oct 2019 17:03:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 085C921734 for ; Tue, 29 Oct 2019 17:03:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lPu1XwPS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 085C921734 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 A87496B0003; Tue, 29 Oct 2019 13:03:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A38046B0005; Tue, 29 Oct 2019 13:03:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94D786B0006; Tue, 29 Oct 2019 13:03:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0112.hostedemail.com [216.40.44.112]) by kanga.kvack.org (Postfix) with ESMTP id 6DA966B0003 for ; Tue, 29 Oct 2019 13:03:57 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 19C6652DE for ; Tue, 29 Oct 2019 17:03:57 +0000 (UTC) X-FDA: 76097444514.12.nut59_5ca1266d09f32 X-HE-Tag: nut59_5ca1266d09f32 X-Filterd-Recvd-Size: 4830 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Oct 2019 17:03:56 +0000 (UTC) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 4017B2173E for ; Tue, 29 Oct 2019 17:03:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572368635; bh=Eia+GZH44EeGJ54mGoLfGXl2InVxm6ZE3joewBlbUhk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lPu1XwPS59/pvfiPwEUwru3NeqNzPFZyXHJBiv4zBAG0aCoMUEOwDTS9nostwp+Ay HL+ByC7tsYHuABMhQn6+RU47q10e1cBxgUkoeStmIdCsxrBt9HV8X8S/efUOg/+n6m oyv1MrV2wbNqTXNyqfE5OlNetLJUfC6dDcl+MnGY= Received: by mail-wm1-f44.google.com with SMTP id r141so3202056wme.4 for ; Tue, 29 Oct 2019 10:03:55 -0700 (PDT) X-Gm-Message-State: APjAAAXhKs+PmIb4u0TM/FGwZKceUPsZE9rbzpH28VhjiPFAPJljQYN/ N8NxEhtB65LFFMaKzD/YGupr2NVQAav4JDMswSvxsg== X-Google-Smtp-Source: APXvYqzJWcbs84/PwCmd/nkZZ5hCGiu24QSMYOGvyu5VK5EpkxoEblrXGkFf/eAJ13JTrsKkAiwZMmn6nzysJ9Qwh0s= X-Received: by 2002:a1c:1fca:: with SMTP id f193mr4715301wmf.173.1572368633735; Tue, 29 Oct 2019 10:03:53 -0700 (PDT) MIME-Version: 1.0 References: <1572171452-7958-1-git-send-email-rppt@kernel.org> <2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com> In-Reply-To: <2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com> From: Andy Lutomirski Date: Tue, 29 Oct 2019 10:03:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings To: "Reshetova, Elena" Cc: Mike Rapoport , "linux-kernel@vger.kernel.org" , Alexey Dobriyan , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Dave Hansen , James Bottomley , Peter Zijlstra , Steven Rostedt , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "linux-api@vger.kernel.org" , "linux-mm@kvack.org" , "x86@kernel.org" , Mike Rapoport , Tycho Andersen , Alan Cox 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 Tue, Oct 29, 2019 at 4:25 AM Reshetova, Elena wrote: > > > The patch below aims to allow applications to create mappins that have > > pages visible only to the owning process. Such mappings could be used to > > store secrets so that these secrets are not visible neither to other > > processes nor to the kernel. > > Hi Mike, > > I have actually been looking into the closely related problem for the past > couple of weeks (on and off). What is common here is the need for userspace > to indicate to kernel that some pages contain secrets. And then there are > actually a number of things that kernel can do to try to protect these secrets > better. Unmap from direct map is one of them. Another thing is to map such > pages as non-cached, which can help us to prevent or considerably restrict > speculation on such pages. The initial proof of concept for marking pages as > "UNCACHED" that I got from Dave Hansen was actually based on mlock2() > and a new flag for it for this purpose. Since then I have been thinking on what > interface suits the use case better and actually selected going with new madvise() > flag instead because of all possible implications for fragmentation and performance. Doing all of this with MAP_SECRET seems bad to me. If user code wants UC memory, it should ask for UC memory -- having the kernel involved in the decision to use UC memory is a bad idea, because the performance impact of using UC memory where user code wasn't expecting it wil be so bad that the system might as well not work at all. (For kicks, I once added a sysctl to turn off caching in CR0. I enabled it in gnome-shell. The system slowed down to such an extent that I was unable to enter the three or so keystrokes to turn it back off.) EXCLUSIVE makes sense. Saying "don't ptrace this" makes sense. UC makes sense. But having one flag to rule them all does not make sense to me.