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 B14A5C433DF for ; Tue, 26 May 2020 06:17:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6B54920878 for ; Tue, 26 May 2020 06:17:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="xEQnl9qu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B54920878 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 168A180080; Tue, 26 May 2020 02:17:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 117E280061; Tue, 26 May 2020 02:17:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 053DF80080; Tue, 26 May 2020 02:17:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id E087080061 for ; Tue, 26 May 2020 02:17:36 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A70904DAC for ; Tue, 26 May 2020 06:17:36 +0000 (UTC) X-FDA: 76857863712.28.feet41_7c9db4a741959 X-HE-Tag: feet41_7c9db4a741959 X-Filterd-Recvd-Size: 3430 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 26 May 2020 06:17:36 +0000 (UTC) Received: from kernel.org (unknown [87.70.212.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 35DCB207CB; Tue, 26 May 2020 06:17:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590473855; bh=mialz6+4JExXiplq4nSrBLYzTjZOqrM1xhFXpnEOLgc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xEQnl9quZ9K04sqX5aILNnhy4om7uaT4xNs8TjpQH8TUR9KN3E3yxcAJNvX/uG07T CdBG05n9SnX45opvfvn4Yr1hTS2GDC6g8fqiXMpisVFocklxDZj3pHqQgeqKEhsipU A/b525HTRdHf10ZM/LvBwefG6D27z5bGPfzDjNag= Date: Tue, 26 May 2020 09:17:21 +0300 From: Mike Rapoport To: Liran Alon Cc: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , David Rientjes , Andrea Arcangeli , Kees Cook , Will Drewry , "Edgecombe, Rick P" , "Kleen, Andi" , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: Re: [RFC 00/16] KVM protected memory extension Message-ID: <20200526061721.GB48741@kernel.org> References: <20200522125214.31348-1-kirill.shutemov@linux.intel.com> <42685c32-a7a9-b971-0cf4-e8af8d9a40c6@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42685c32-a7a9-b971-0cf4-e8af8d9a40c6@oracle.com> 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, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote: > > On 22/05/2020 15:51, Kirill A. Shutemov wrote: > > Furthermore, I would like to point out that just unmapping guest data from > kernel direct-map is not sufficient to prevent all > guest-to-guest info-leaks via a kernel memory info-leak vulnerability. This > is because host kernel VA space have other regions > which contains guest sensitive data. For example, KVM per-vCPU struct (which > holds vCPU state) is allocated on slab and therefore > still leakable. Objects allocated from slab use the direct map, vmalloc() is another story. > > - Touching direct mapping leads to fragmentation. We need to be able to > > recover from it. I have a buggy patch that aims at recovering 2M/1G page. > > It has to be fixed and tested properly > > As I've mentioned above, not mapping all guest memory from 1GB hugetlbfs > will lead to holes in kernel direct-map which force it to not be mapped > anymore as a series of 1GB huge-pages. > This have non-trivial performance cost. Thus, I am not sure addressing this > use-case is valuable. Out of curiosity, do we actually have some numbers for the "non-trivial performance cost"? For instance for KVM usecase? -- Sincerely yours, Mike.