Subject: [RFC PATCH] uprobes: copy to user-space xol page with proper cache flushing

From: [email-masked] (Oleg Nesterov)
Date: Tue, 15 Apr 2014 19:49:00 +0200

On 04/15, David Miller wrote:
>
> From: David Long <[email-masked]>
> Date: Tue, 15 Apr 2014 13:19:27 -0400
>
> > On 04/15/14 11:46, Oleg Nesterov wrote:
> >>
> >> But. Please do not add copy_to_user_page() into copy_to_page() (as your patch
> >> did). This is certainly not what uprobe_write_opcode() wants, we do not want
> >> or need "flush" in this case. The same for __create_xol_area().
> >>
> >
> > It looked me like a call to a new __copy_to_user_page(current->mm, ...) in xol_get_insn_slot()
> > would be in line with David Miller's suggestion and would cure the problem on ARM (and hopefuly
> > be more philosophically correct for all architectures):
>
> It occurs to me that because of the specific environment in which this
> executes we can make the interface take advantage of the invariants at
> this call site:
>
> 1) We are copying into userspace and thus current->mm
>
> 2) We are only storing an instruction or two

Not sure this can help, but also

  3) nobody else will even read/execute this peace of memory

> Furthermore, we can do the stores using something akin to put_user(),
> directly store them into userspace.
>
> This avoids completely any D-cache aliasing issues.  The kernel stores
> to the same address, and therefore the same cache lines, as userspace
> would.

Heh. Of course I thought about this. This can not work afaics.

We do not want to write to, say, page cache if the probed application
mmaps a file at the same vaddr.

Oleg.