[PATCH 0 of 2] Fix correctness race in xc_mem_paging_prep

[PATCH 0 of 2] Fix correctness race in xc_mem_paging_prep

[Andres Lagar-Cavilla]

ging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for this page. 
Foreign mappings of the gfn will now succeed. This is the key idea, as it 
allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Second patch is a tools patch, cc'ed maintainers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  52 +++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 +++++-
 tools/libxc/xc_mem_event.c   |   4 +-
 tools/libxc/xc_mem_paging.c  |  23 +++++++++++++++++++
 tools/libxc/xenctrl.h        |   2 +
 8 files changed, 85 insertions(+), 10 deletions(-)

[PATCH 0 of 2] Fix correctness race in xc_mem_paging_prep

[Andres Lagar-Cavilla]

P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for this page. 
Foreign mappings of the gfn will now succeed. This is the key idea, as it 
allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Second patch is a tools patch, cc'ed maintainers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  52 +++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 +++++-
 tools/libxc/xc_mem_event.c   |   4 +-
 tools/libxc/xc_mem_paging.c  |  23 +++++++++++++++++++
 tools/libxc/xenctrl.h        |   2 +
 8 files changed, 85 insertions(+), 10 deletions(-)

Re: [PATCH 0 of 2] Fix correctness race in xc_mem_paging_prep

[Olaf Hering]

On Tue, Nov 29, Andres Lagar-Cavilla wrote:

> P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> transitions to the next state in the paging state machine for this page. 
> Foreign mappings of the gfn will now succeed. This is the key idea, as it 
> allows the pager to now map the gfn and fill in its contents.
> 
> Unfortunately, it also allows any other foreign mapper to map the gfn and read
> its contents. This is particularly dangerous when the populate is launched
> by a foreign mapper in the first place, which will be actively retrying the
> map operation and might race with the pager. Qemu-dm being a prime example.

Yes, I think thats a real issue. The concept looks ok to me.

Olaf

Re: [PATCH 0 of 2] Fix correctness race in xc_mem_paging_prep

[Olaf Hering]

On Wed, Nov 30, Olaf Hering wrote:

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
> 
> > P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> > transitions to the next state in the paging state machine for this page. 
> > Foreign mappings of the gfn will now succeed. This is the key idea, as it 
> > allows the pager to now map the gfn and fill in its contents.
> > 
> > Unfortunately, it also allows any other foreign mapper to map the gfn and read
> > its contents. This is particularly dangerous when the populate is launched
> > by a foreign mapper in the first place, which will be actively retrying the
> > map operation and might race with the pager. Qemu-dm being a prime example.
> 
> Yes, I think thats a real issue. The concept looks ok to me.

After some more thought I think we can kill two birds with one stone:

- merge p2m_mem_paging_prep() into p2m_mem_paging_resume().
p2m_mem_paging_populate() maintains a list of buffer pages and passes
one of them to the pager. The pager fills the buffer and passes it back
to p2m_mem_paging_resume() which copies that buffer into a newly
allocated page. Once the p2mt state is restored the buffer is released
for further uses in p2m_mem_paging_populate().
Its just the question: how to handle allocation failures?

- if both functions are merged, the communication between 
p2m_mem_paging_drop()/p2m_mem_paging_populate() and
p2m_mem_paging_resume() could be done entirely with th event channel.
The two domctls can disappear and also a p2mt could be removed. So both
page-out and page-in will be a two-step process.

What do you think about that idea?

Olaf