Michael Ellerman [m...@ellerman.id.au] wrote: > Sukadev Bhattiprolu <suka...@linux.vnet.ibm.com> writes: > > > Nicholas Piggin [npig...@gmail.com] wrote: > >> On Mon, 14 Aug 2017 15:21:48 +1000 > >> Michael Ellerman <m...@ellerman.id.au> wrote: > >> > >> > Sukadev Bhattiprolu <suka...@linux.vnet.ibm.com> writes: > >> > >> > > arch/powerpc/include/asm/vas.h | 35 ++++ > >> > > arch/powerpc/include/uapi/asm/vas.h | 25 +++ > >> > > >> > I thought we weren't exposing VAS to userspace yet? > >> > > >> > If we are then we need to get things straight WRT copy/paste abort. > ... > > > > In the FTW case, there is no data transfer from user space to the hardware.
Sorry, that was focussed on the paste side. > > i.e the copy/paste submit a NULL CRB and hardware will be configured (see > > ->fifo_disable setting in winctx) to ignore any data they specify in the > > CRB. > > I thought the copy did copy a cacheline, but then the paste to the VAS > window just ignores the contents, and doesn't allow userspace to get the > content in any way? Yes, you are right. The copy instruction does read the CRB into its copy- buffer but for the FTW, VAS ignores the copy-buffer contents on paste. So, the CRB may be zeroed, but must be a valid buffer. > > Which means we have two thirds of a covert channel, ie. something can be > copied into the copy buffer by one process, and then a second process > can paste it, but because it can only paste to foreign memory, and the > only foreign memory it can get is a VAS FTW window, it can't actually > see the content of the copy buffer. > > > Would we be able to allow copy/paste from user space in that case? > > Yeah I think so, but it is all a bit fragile. > > cheers