linux-kernel - Re: [PATCH] x86, kvm: Handle PFNs outside of kernel reach when touching GPTEs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1b77a9a3-6fc0-1258-026e-5977a6e9dba6@gmail.com>
Date:   Mon, 17 Apr 2017 19:26:09 +0800
From:   Xiao Guangrong <guangrong.xiao@...il.com>
To:     "Sironi, Filippo" <sironi@...zon.de>,
        Radim Krčmář <rkrcmar@...hat.com>
Cc:     "Liguori, Anthony" <aliguori@...zon.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86, kvm: Handle PFNs outside of kernel reach when
 touching GPTEs



On 04/12/2017 09:16 PM, Sironi, Filippo wrote:
> Thanks for taking the time and sorry for the delay.
>
>> On 6. Apr 2017, at 16:22, Radim Krčmář <rkrcmar@...hat.com> wrote:
>>
>> 2017-04-05 15:07+0200, Filippo Sironi:
>>> cmpxchg_gpte() calls get_user_pages_fast() to retrieve the number of
>>> pages and the respective struct pages for mapping in the kernel virtual
>>> address space.
>>> This doesn't work if get_user_pages_fast() is invoked with a userspace
>>> virtual address that's backed by PFNs outside of kernel reach (e.g.,
>>> when limiting the kernel memory with mem= in the command line and using
>>> /dev/mem to map memory).
>>>
>>> If get_user_pages_fast() fails, look up the VMA that backs the userspace
>>> virtual address, compute the PFN and the physical address, and map it in
>>> the kernel virtual address space with memremap().
>>
>> What is the reason for a configuration that voluntarily restricts access
>> to memory that it needs?
>
> By using /dev/mem to provide VM memory, one can avoid the overhead of allocating struct page(s) for the whole memory, which is wasteful when using a server entirely for hosting VMs.
>

Sounds reasonable, however it is incomplete so far as there are some
code paths still do not support non-page backend memory, e.g,
emulator_cmpxchg_emulated().

I would suggest to unify the code introduced in this patch with existing
hva_to_pfn(), also we can introduce a common API, maybe named
kvm_map_hva(), to improve the caller sides.


BTW, i do not know why we used kmap_atomic() rather than kmap(), the
path of cmpxchg_gpte() is sleep-able anyway.

Thanks!