Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1710655 > unrolled thread

Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields  and structures Nicholas Piggin <npiggin@gmail.com> - 2017-08-14 08:10 +0200
    Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures Michael Ellerman <mpe@ellerman.id.au> - 2017-08-14 13:10 +0200
    Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and  structures Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> - 2017-08-14 21:20 +0200
      Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures Michael Ellerman <mpe@ellerman.id.au> - 2017-08-16 14:10 +0200
        Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and  structures Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> - 2017-08-17 01:10 +0200

#1710655 — Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

On Mon, 14 Aug 2017 15:21:48 +1000
Michael Ellerman <mpe@ellerman.id.au> wrote:

> Sukadev Bhattiprolu <sukadev@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.

No we should not be. This might be just a leftover hunk that should
be moved to a future series.

At the moment (as far as I understand) it should be limited to
preempt-disabled, process context, kernel users which avoids any
concern for switch_to.

Thanks,
Nick

[toc] | [next] | [standalone]

#1710830 — Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

Nicholas Piggin <npiggin@gmail.com> writes:

> On Mon, 14 Aug 2017 15:21:48 +1000
> Michael Ellerman <mpe@ellerman.id.au> wrote:
>
>> Sukadev Bhattiprolu <sukadev@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.
>
> No we should not be. This might be just a leftover hunk that should
> be moved to a future series.
>
> At the moment (as far as I understand) it should be limited to
> preempt-disabled, process context, kernel users which avoids any
> concern for switch_to.

I think that comment applied to a previous version, see patch 16.

cheers

[toc] | [prev] | [next] | [standalone]

#1711369 — Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

Nicholas Piggin [npiggin@gmail.com] wrote:
> On Mon, 14 Aug 2017 15:21:48 +1000
> Michael Ellerman <mpe@ellerman.id.au> wrote:
> 
> > Sukadev Bhattiprolu <sukadev@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.
> 

> No we should not be. This might be just a leftover hunk that should
> be moved to a future series.

Yes, I should have posted patches 14..17 separately as an RFC that goes
on top of the VAS kernel patches 1..13.

> 
> At the moment (as far as I understand) it should be limited to
> preempt-disabled, process context, kernel users which avoids any
> concern for switch_to.
> 

In the FTW case, there is no data transfer from user space to the hardware.
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.

Would we be able to allow copy/paste from user space in that case?

Sukadev

[toc] | [prev] | [next] | [standalone]

#1712885 — Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:

> Nicholas Piggin [npiggin@gmail.com] wrote:
>> On Mon, 14 Aug 2017 15:21:48 +1000
>> Michael Ellerman <mpe@ellerman.id.au> wrote:
>> 
>> > Sukadev Bhattiprolu <sukadev@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.
> 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?

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

[toc] | [prev] | [next] | [standalone]

#1713403 — Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

Michael Ellerman [mpe@ellerman.id.au] wrote:
> Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:
> 
> > Nicholas Piggin [npiggin@gmail.com] wrote:
> >> On Mon, 14 Aug 2017 15:21:48 +1000
> >> Michael Ellerman <mpe@ellerman.id.au> wrote:
> >> 
> >> > Sukadev Bhattiprolu <sukadev@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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web