Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC 00/16] KVM protected memory extension
To:     Mike Rapoport <rppt@kernel.org>
Cc:     "Kirill A. Shutemov" <kirill@shutemov.name>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        David Rientjes <rientjes@google.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Kees Cook <keescook@chromium.org>,
        Will Drewry <wad@chromium.org>,
        "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
        "Kleen, Andi" <andi.kleen@intel.com>, x86@kernel.org,
        kvm@vger.kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
References: <20200522125214.31348-1-kirill.shutemov@linux.intel.com>
 <42685c32-a7a9-b971-0cf4-e8af8d9a40c6@oracle.com>
 <20200526061721.GB48741@kernel.org>
From:   Liran Alon <liran.alon@oracle.com>
Message-ID: <8866ff79-e8fd-685d-9a1d-72acff5bf6bb@oracle.com>
Date:   Tue, 26 May 2020 13:16:14 +0300
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0)
 Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200526061721.GB48741@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 26/05/2020 9:17, Mike Rapoport wrote:
> 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.
It doesn't matter. This patch series, like XPFO, only removes guest 
memory pages from direct-map.
Not things such as KVM per-vCPU structs. That's why Julian & Marius 
(AWS), created the "Process local kernel VA region" patch-series
that declare a single PGD entry, which maps a kernelspace region, to 
have different PFN between different tasks.
For more information, see my KVM Forum talk slides I gave in previous 
reply and related AWS patch-series:
https://patchwork.kernel.org/cover/10990403/
>
>>>    - 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?
>
Dig into XPFO mailing-list discussions to find out...
I just remember that this was one of the main concerns regarding XPFO.

-Liran