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: <20150102181908.GA8466@redhat.com>
Date:	Fri, 2 Jan 2015 19:19:08 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Pratyush Anand <panand@...hat.com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux@....linux.org.uk,
	tixy@...aro.org, ananth@...ibm.com, sandeepa.prabhu@...aro.org,
	catalin.marinas@....com, will.deacon@....com,
	linux-kernel@...r.kernel.org, anil.s.keshavamurthy@...el.com,
	masami.hiramatsu.pt@...achi.com, wcohen@...hat.com
Subject: Re: [RFC 5/8] ARM64: Re-factor flush_ptrace_access

On 01/02, Oleg Nesterov wrote:
>
> On 12/31, Pratyush Anand wrote:
> >
> > Re-factor flush_ptrace_access to reuse vma independent part.
>
> But for what? The changelog should explain this.
>
> > Signed-off-by: Pratyush Anand <panand@...hat.com>
> > ---
> >  arch/arm64/mm/flush.c | 24 +++++++++++++++---------
> >  1 file changed, 15 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
> > index b6f14e8d2121..9a4dd6f39cfb 100644
> > --- a/arch/arm64/mm/flush.c
> > +++ b/arch/arm64/mm/flush.c
> > @@ -34,19 +34,25 @@ void flush_cache_range(struct vm_area_struct *vma, unsigned long start,
> >  		__flush_icache_all();
> >  }
> >
> > +static void __flush_ptrace_access(struct page *page, unsigned long uaddr,
> > +		void *kaddr, unsigned long len)
> > +{
> > +	unsigned long addr = (unsigned long)kaddr;
> > +
> > +	if (icache_is_aliasing()) {
> > +		__flush_dcache_area(kaddr, len);
> > +		__flush_icache_all();
> > +	} else {
> > +		flush_icache_range(addr, addr + len);
> > +	}
> > +}
> > +
> >  static void flush_ptrace_access(struct vm_area_struct *vma, struct page *page,
> >  				unsigned long uaddr, void *kaddr,
> >  				unsigned long len)
> >  {
> > -	if (vma->vm_flags & VM_EXEC) {
> > -		unsigned long addr = (unsigned long)kaddr;
> > -		if (icache_is_aliasing()) {
> > -			__flush_dcache_area(kaddr, len);
> > -			__flush_icache_all();
> > -		} else {
> > -			flush_icache_range(addr, addr + len);
> > -		}
> > -	}
> > +	if (vma->vm_flags & VM_EXEC)
> > +		__flush_ptrace_access(page, uaddr, kaddr, len);
> >  }
>
> So why uprobes can't use flush_ptrace_access() ? flush_uprobe_xol_access() is
> called by arch_uprobe_copy_ixol(), and xol vma has VM_EXEC bit set.

Ah, sorry, I forgot that arch_uprobe_copy_ixol() doesn't have "vma" so it
can't use flush_ptrace_access()... perhaps you can update the changelog.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ