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=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 B0EC4C433E0 for ; Tue, 2 Feb 2021 18:17:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 62613601FB for ; Tue, 2 Feb 2021 18:17:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 62613601FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=viXzOeObMR2W+hn9eV8HIU8+FjhkUMgN81GUAPo4FIw=; b=efApnTHrSZF7PVLEejcsOYrKa kTFBDiT1VhphsdP1KVN7/RsUNW3HCy/1tvzAdImP/rRBXyBrXa53qaHWd/s/axB5QDGfTc6LFihuP zKiZTJd1WIYsPeeIobuc6sZmSx/MQaDrVSUYElTlV2r1KDctUZ9phpprqVlqjglPz1grsJ1axUbGY YJ+K+AQGwWVZYdauAbKWWSkl4fWbWFmPVIFsCDlYJl6sRtcysn5aNuAvVki+Vo7NTTPsLZ8feDTyb KS7TURyQb+5KQ9zv+WI3vbjXRuC/H8WB3UNCLPIh3EO0pOweOJiEo+cwadyjCs61JfmE92tREtION F1+EHtM+Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l70Do-00049T-3M; Tue, 02 Feb 2021 18:16:16 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l70Dk-000487-IZ; Tue, 02 Feb 2021 18:16:13 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9084864F92; Tue, 2 Feb 2021 18:15:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612289771; bh=jExAi6+S0KhwmLELocI6wMJuzz/tLWY8R7yvg8v3kSM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EDgDXp2MRosyELVG93hsa2FWpra6U+O1s/wok5z4I/qOXv7rdUmjG2axPtMIvq+YN yBgA8wcWgNGCYn0pW2zVsZsv3wcPZETui3XjKumHzFywKHgYsDnq+d0PEjUY80BQCe IzesvjbDuB+UAqmSCfbvnjKvS7w0UCcntNSHwnveAp/98Y5aklQbVLZ5aIeTMaBtIb Y2S9E4/e0RHCm573D5HvZcykwBcZPsiKWKBYdn9Gm25wRz155OpIc0oI5MY1vEx2Z5 y6k9c5Z7N9NTPpMQGOvaiK4lasHyvoskCgCDKMvmuqHqWSSfiiKO+c0UX4uuveVSEz Bmm6b/PXs32Ig== Date: Tue, 2 Feb 2021 20:15:46 +0200 From: Mike Rapoport To: David Hildenbrand Subject: Re: [PATCH v16 07/11] secretmem: use PMD-size pages to amortize direct map fragmentation Message-ID: <20210202181546.GO242749@kernel.org> References: <6de6b9f9c2d28eecc494e7db6ffbedc262317e11.camel@linux.ibm.com> <20210202124857.GN242749@kernel.org> <6653288a-dd02-f9de-ef6a-e8d567d71d53@redhat.com> <211f0214-1868-a5be-9428-7acfc3b73993@redhat.com> <95625b83-f7e2-b27a-2b99-d231338047fb@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <95625b83-f7e2-b27a-2b99-d231338047fb@redhat.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210202_131612_735393_C921A122 X-CRM114-Status: GOOD ( 21.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Michal Hocko , Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Shuah Khan , Thomas Gleixner , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Palmer Dabbelt , Arnd Bergmann , James Bottomley , Hagen Paul Pfeifer , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Dan Williams , linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Palmer Dabbelt , linux-fsdevel@vger.kernel.org, Shakeel Butt , Andrew Morton , Rick Edgecombe , Roman Gushchin Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 02, 2021 at 03:34:29PM +0100, David Hildenbrand wrote: > On 02.02.21 15:32, Michal Hocko wrote: > > On Tue 02-02-21 15:26:20, David Hildenbrand wrote: > > > On 02.02.21 15:22, Michal Hocko wrote: > > > > On Tue 02-02-21 15:12:21, David Hildenbrand wrote: > > > > [...] > > > > > I think secretmem behaves much more like longterm GUP right now > > > > > ("unmigratable", "lifetime controlled by user space", "cannot go on > > > > > CMA/ZONE_MOVABLE"). I'd either want to reasonably well control/limit it or > > > > > make it behave more like mlocked pages. > > > > > > > > I thought I have already asked but I must have forgotten. Is there any > > > > actual reason why the memory is not movable? Timing attacks? > > > > > > I think the reason is simple: no direct map, no copying of memory. > > > > This is an implementation detail though and not something terribly hard > > to add on top later on. I was more worried there would be really > > fundamental reason why this is not possible. E.g. security implications. > > I don't remember all the details. Let's see what Mike thinks regarding > migration (e.g., security concerns). Thanks for considering me a security expert :-) Yet, I cannot estimate how dangerous is the temporal exposure of this data to the kernel via the direct map in the simple map/copy/unmap sequence. More secure way would be to map source and destination in a different page table rather than in the direct map, similarly to the way text_poke() on x86 does. I've left the migration callback empty for now because it can be added on top and its implementation would depend on the way we do (or do not do) pooling. -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel