[PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

[Catalin Marinas]

On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long addr,
>  	if (opt == PR_SET_MM_AUXV)
>  		return prctl_set_auxv(mm, addr, arg4);
>  
> -	if (addr >= TASK_SIZE || addr < mmap_min_addr)
> +	if (untagged_addr(addr) >= TASK_SIZE ||
> +			untagged_addr(addr) < mmap_min_addr)
>  		return -EINVAL;
>  
>  	error = -EINVAL;
>  
>  	down_write(&mm->mmap_sem);
> -	vma = find_vma(mm, addr);
> +	vma = find_vma(mm, untagged_addr(addr));
>  
>  	prctl_map.start_code	= mm->start_code;
>  	prctl_map.end_code	= mm->end_code;

Does this mean that we are left with tagged addresses for the
mm->start_code etc. values? I really don't think we should allow this,
I'm not sure what the implications are in other parts of the kernel.

Arguably, these are not even pointer values but some address ranges. I
know we decided to relax this notion for mmap/mprotect/madvise() since
the user function prototypes take pointer as arguments but it feels like
we are overdoing it here (struct prctl_mm_map doesn't even have
pointers).

What is the use-case for allowing tagged addresses here? Can user space
handle untagging?

-- 
Catalin