[RFC PATCH v4] ARM: uprobes xol write directly to userspace

Oleg Nesterov oleg at redhat.com
Wed Apr 16 07:51:07 PDT 2014


On 04/15, Victor Kamensky wrote:
>
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1149,7 +1149,7 @@ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area)
>  	}
>
>  	ret = install_special_mapping(mm, area->vaddr, PAGE_SIZE,
> -				VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, &area->page);
> +				VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_WRITE, &area->page);

Yes, this is nasty.

I would like to have a reason to nack this change ;) Unfortunately the current
code is buggy too and we need to protect the kernel from malicious applications
which can rewrite the insn we are going to step over in UTASK_SSTEP state anyway.

> +void __weak arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
> +				  void *src, unsigned long len)
> +{
> +	/*
> +	 * Note if CPU does not support instructions write snooping
> +	 * from dcache it needs to define its own version of this
> +	 * function that would take care of proper cache flushes.
> +	 *
> +	 * Nothing we can do if it fails, added if to make unused
> +	 * result warning happy. If xol write failed because process
> +	 * unmapped xol area by mistake, process will crash in some
> +	 * other place.
> +	 */
> +	if (__copy_to_user((void *) vaddr, src, len));
> +}

Plus, again, this can write to another mapping, say to file-backed memory.

Finally, with this change it won't be possible to share this xol memory with
other tasks.

But it seems that it is pointless to argue.

Oleg.




More information about the linux-arm-kernel mailing list