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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,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 66731CA9EC2 for ; Tue, 29 Oct 2019 05:44:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2AF9320874 for ; Tue, 29 Oct 2019 05:44:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="KNzW/V7s" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2AF9320874 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C87966B0007; Tue, 29 Oct 2019 01:44:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C38BD6B0008; Tue, 29 Oct 2019 01:44:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B27826B000A; Tue, 29 Oct 2019 01:44:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) by kanga.kvack.org (Postfix) with ESMTP id 8E1696B0007 for ; Tue, 29 Oct 2019 01:44:04 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 172FE8249980 for ; Tue, 29 Oct 2019 05:44:04 +0000 (UTC) X-FDA: 76095731208.06.spy91_7ac1c16177e34 X-HE-Tag: spy91_7ac1c16177e34 X-Filterd-Recvd-Size: 5320 Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Oct 2019 05:44:03 +0000 (UTC) Received: by mail-io1-f68.google.com with SMTP id q1so13457856ion.1 for ; Mon, 28 Oct 2019 22:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TwIi5AOjL+xogOCvS6bHBwjeQf/wLwbiipgSMMh0034=; b=KNzW/V7sWJosoX1Wgya+9xFpsAsFfo6DDBqfmWMNyaScGVynI6XSo7d+lwmrMWZxZL DvRnMNBLvZ0EHRASZudom7+529D69Ioa/0D7baXzLTNV1FPTwLomqDyT/QmJcxb5Du1U NSTkEadBjUQMLQPVj82sdWfYNZOwCSsWTG+L0Qx8obhz7U70EuP25ilO3ICo4oNGcrO3 sP0elWbXJEHp6oYJxQSMdD7e5pm22CHlDhcBkpOgjJK1GmkKT8A2loNgtllFUY87GsSZ jNGDO3LVk14ot8lzEpFm3D45nS/xqU+HmDNj9xCjAxZlph83JhmRRF+2rMkfYu3bGp43 DIbQ== 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=TwIi5AOjL+xogOCvS6bHBwjeQf/wLwbiipgSMMh0034=; b=r2mxbSNRGovqWn4GJ9BHNJZyv9PIue+VsSakizualHlmpQT6XjjlhnbkCwn3MpxoBJ RZQi+6z93ueo6cQA62l3S9gJM0reGMR+KVRvt62JlEg8tNdLxjHDBo3cgwT+w9dmxPSn TEkTM9zhPKB8xBonsmaD+F7sTeAg7B824t9cQgx6MpQTsKEviZb9i4ZdEbzQ2TUYc7vX Hrx/MFEfFB6CCpYvrKYiPyXEgqQU1BbJArGkpWz6c3K9NBjCB79lIqd03YAIKwUqFov5 cespcy9Yqn8X3O59zQIOm6WwEjt5UjJbDjYDZ/rhXAPkbO42EA67ij1EtcXXs45+J4dE J8PQ== X-Gm-Message-State: APjAAAXQm7m1en4WTt+mVc9cA+ZE4aLtTtxlmnskX4qUCURCkUmSovGA zs7xWIwHSl+3kjEU4govsk+7Y7kW3j9qIYJrXEc= X-Google-Smtp-Source: APXvYqwfnx5VqN5e72dkTUgm4SNDz5ZOunVAy0hTGiBY9L2ixHUF+ZWjMafnA/vc/o+iuu7rYO8ulvkWS150jm+d+Kc= X-Received: by 2002:a5d:9b83:: with SMTP id r3mr1724580iom.5.1572327842597; Mon, 28 Oct 2019 22:44:02 -0700 (PDT) MIME-Version: 1.0 References: <1572171452-7958-1-git-send-email-rppt@kernel.org> <1572171452-7958-2-git-send-email-rppt@kernel.org> <20191028123124.ogkk5ogjlamvwc2s@box> <20191028130018.GA7192@rapoport-lnx> <20191028131623.zwuwguhm4v4s5imh@box> In-Reply-To: <20191028131623.zwuwguhm4v4s5imh@box> From: Dan Williams Date: Mon, 28 Oct 2019 22:43:51 -0700 Message-ID: Subject: Re: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings To: "Kirill A. Shutemov" Cc: Mike Rapoport , Linux Kernel Mailing List , 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 , linux-mm , "the arch/x86 maintainers" , Mike Rapoport 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, Oct 28, 2019 at 6:16 AM Kirill A. Shutemov wrote: > > On Mon, Oct 28, 2019 at 02:00:19PM +0100, Mike Rapoport wrote: > > On Mon, Oct 28, 2019 at 03:31:24PM +0300, Kirill A. Shutemov wrote: > > > On Sun, Oct 27, 2019 at 12:17:32PM +0200, Mike Rapoport wrote: > > > > From: Mike Rapoport > > > > > > > > The mappings created with MAP_EXCLUSIVE are visible only in the context of > > > > the owning process and can be used by applications to store secret > > > > information that will not be visible not only to other processes but to the > > > > kernel as well. > > > > > > > > The pages in these mappings are removed from the kernel direct map and > > > > marked with PG_user_exclusive flag. When the exclusive area is unmapped, > > > > the pages are mapped back into the direct map. > > > > > > I probably blind, but I don't see where you manipulate direct map... > > > > __get_user_pages() calls __set_page_user_exclusive() which in turn calls > > set_direct_map_invalid_noflush() that makes the page not present. > > Ah. okay. > > I think active use of this feature will lead to performance degradation of > the system with time. > > Setting a single 4k page non-present in the direct mapping will require > splitting 2M or 1G page we usually map direct mapping with. And it's one > way road. We don't have any mechanism to map the memory with huge page > again after the application has freed the page. > > It might be okay if all these pages cluster together, but I don't think we > have a way to achieve it easily. Still, it would be worth exploring what that would look like if not for MAP_EXCLUSIVE then set_mce_nospec() that wants to punch out poison pages from the direct map. In the case of pmem, where those pages are able to be repaired, it would be nice to also repair the mapping granularity of the direct map.