linux-kernel - Re: [RFC 5/8] ARM64: Re-factor flush_ptrace

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]

Date:	Sun, 04 Jan 2015 19:20:41 +0530
From:	Pratyush Anand <panand@...hat.com>
To:	Oleg Nesterov <oleg@...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 Friday 02 January 2015 11:49 PM, Oleg Nesterov wrote:
> 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.
>

OK.. Will improve commit log.

~Pratyush
> 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/