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 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 20840CA9EBD for ; Sun, 27 Oct 2019 11:00:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D800721928 for ; Sun, 27 Oct 2019 11:00:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="nWmDdz95" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D800721928 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 5AD296B0003; Sun, 27 Oct 2019 07:00:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 55D7A6B0006; Sun, 27 Oct 2019 07:00:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44C066B0007; Sun, 27 Oct 2019 07:00:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id 26AFA6B0003 for ; Sun, 27 Oct 2019 07:00:24 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id BAB55180ACC20 for ; Sun, 27 Oct 2019 11:00:23 +0000 (UTC) X-FDA: 76089270726.18.girls33_36499fe5a435 X-HE-Tag: girls33_36499fe5a435 X-Filterd-Recvd-Size: 3025 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Sun, 27 Oct 2019 11:00:23 +0000 (UTC) Received: from [10.173.153.26] (unknown [2.55.42.38]) (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 6F46D214AF; Sun, 27 Oct 2019 11:00:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572174022; bh=Jmt2B0VEl/FUjM+MgzpTzTtF3WYLk8v8TfnsbPH95BE=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=nWmDdz95jS72TenFW6vwu5hnpkWGaIk+42GN2FxxDR78HF8zBHoIhwHWcd2Rwlzhz BPaAzQljyMUopkP2ab89nUBAsWWGu6p1Oluy9j+CscUuN7lszAK4lXsB7HKKXgQ3LN biHkcQoaYhqZmf4mRHOemJcXCiJq/wuyvnKN1xoY= Date: Sun, 27 Oct 2019 13:00:13 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <87d0eieb0i.fsf@mid.deneb.enyo.de> References: <1572171452-7958-1-git-send-email-rppt@kernel.org> <87d0eieb0i.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings To: Florian Weimer CC: 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 From: Mike Rapoport Message-ID: <385EB6D4-A1B0-4617-B256-181AA1C3BDE3@kernel.org> 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 October 27, 2019 12:30:21 PM GMT+02:00, Florian Weimer wrote: >* Mike Rapoport: > >> The patch below aims to allow applications to create mappins that >have >> pages visible only to the owning process=2E Such mappings could be used >to >> store secrets so that these secrets are not visible neither to other >> processes nor to the kernel=2E > >How is this expected to interact with CRIU? CRIU dumps the memory contents using a parasite code from inside the dumpe= e address space, so it would work the same way as for the other mappings=2E= Of course, at the restore time the exclusive mapping should be recreated w= ith the appropriate flags=2E >> I've only tested the basic functionality, the changes should be >verified >> against THP/migration/compaction=2E Yet, I'd appreciate early feedback= =2E > >What are the expected semantics for VM migration? Should it fail? I don't quite follow=2E If qemu would use such mappings it would be able t= o transfer them during live migration=2E --=20 Sincerely yours, Mike