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>] [day] [month] [year] [list]
Date:   Sat, 10 Mar 2018 11:48:30 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     <peng.hao2@....com.cn>
Cc:     <linux-arm-kernel@...ts.infradead.org>,
        <kvmarm@...ts.cs.columbia.edu>, <linux-kernel@...r.kernel.org>,
        <cdall@...nel.org>
Subject: Re: [PATCH] KVM:arm/arm64: dcache need be coherent unconditionally

On Sat, 10 Mar 2018 03:23:18 +0000,
peng hao wrote:

> >> For emulation devices just like vga, keeping coherent dcache between
> >> guest and host timely is needed.
> >> Now the display of vnc-viewer will not update continuously and the
> >> patch can fix up.
> >> 
> >> Signed-off-by: Peng Hao <peng.hao2@....com.cn>
> >> ---
> >>  virt/kvm/arm/mmu.c | 6 ++----
> >>  1 file changed, 2 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> >> index ec62d1c..4a28395e 100644
> >> --- a/virt/kvm/arm/mmu.c
> >> +++ b/virt/kvm/arm/mmu.c
> >> @@ -1416,8 +1416,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>              kvm_set_pfn_dirty(pfn);
> >>          }
> >>  
> >> -        if (fault_status != FSC_PERM)
> >> -            clean_dcache_guest_page(pfn, PMD_SIZE);
> >> +        clean_dcache_guest_page(pfn, PMD_SIZE);
> >>  
> >>          if (exec_fault) {
> >>              new_pmd = kvm_s2pmd_mkexec(new_pmd);
> >> @@ -1438,8 +1437,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>              mark_page_dirty(kvm, gfn);
> >>          }
> >>  
> >> -        if (fault_status != FSC_PERM)
> >> -            clean_dcache_guest_page(pfn, PAGE_SIZE);
> >> +        clean_dcache_guest_page(pfn, PAGE_SIZE);
> >>  
> >>          if (exec_fault) {
> >>              new_pte = kvm_s2pte_mkexec(new_pte);
> >> 
> 
> >I'm sorry, but I have to NAK this.
> 
> >You're papering over the fundamental issue that you're accessing a
> >cacheable alias of a non cacheable memory. The architecture is very
> >clear about why this doesn't work, and KVM implements the architecture.
> 
> 
> 
> I find that I just encounter the problem after the commit
> '15303ba5d1cd9b28d03a980456c0978c0ea3b208 " .

This should really be a9c0e12ebee5 ("KVM: arm/arm64: Only clean the
dcache on translation fault").

> The commit contains "icache invalidation optimizations, improving VM
> startup time",it changes from unconditionally calling
> coherent_cache_guest_page(including dcache handle) to conditionally
> calling clean_dcache_guest_page.
> 
> I trace the display of vnc abnormally and find it generate data
> abort in vga address region with FSC_PERM,and it will not call
> clean_dcache_guest_page . So I think should recover to uncontionally
> calling clean_dcache_guest_page.

[I really hate ranting on a Saturday morning as the sun is finally out
and I could be relaxing in the garden, but hey, I guess that's the
fate of a kernel hacker who made the silly mistake of reading email on
a Saturday morning instead of being out in the garden...]

Even if you enabled dirty tracking on the VGA memory (and thus making
it RO to generate a permission fault), you would end-up cleaning to
the PoC *before* any write has been committed to the page. How useful
is that? You're also pretty lucky that this does a clean+invalidate
(rather than a clean which would be good enough), meaning that QEMU
will in turn miss in the cache (PIPT caches) and read some *stale*
data from memory.

Repeat that often enough, and yes, you can get some sort of
display. Is that the right thing to do? Hell no. You might just as
well have a userspace process thrashing the cache at the PoC, running
concurrently with your VM, it would have a similar effect. It may work
on your particular platform, in some specific conditions, but it just
doesn't work in general.

What you are describing is a long standing issue. VGA emulation never
worked on ARM, because it is fundamentally incompatible with the ARM
memory architecture. Read the various discussions on the list over the
past 4 years or so, read the various presentations I and others have
given about this problem and how to address it[1].

The *real* fix is a one-liner in the Linux VGA driver: map the VGA
memory as cacheable, and stop lying to the guest. Or if you want to
lie to the guest, perform cache maintenance from userspace in QEMU
based on the dirty tracking bitmap that it uses for the VGA memory.

Anything else is out of the scope of the architecture, and I'm not
going to add more crap to satisfy requirements that cannot be
implemented on real HW, let alone in a virtualized environment.

Thanks,

	M.

[1] http://events17.linuxfoundation.org/sites/events/files/slides/slides_10.pdf

-- 
Jazz is not dead, it just smell funny.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ