Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 22 Oct 2021 08:58:35 -0400
From:   Bruce Fields <bfields@fieldses.org>
To:     dai.ngo@oracle.com
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Steve Dickson <steved@redhat.com>,
        Olga Kornievskaia <olga.kornievskaia@gmail.com>,
        Chuck Lever <chuck.lever@oracle.com>
Subject: Re: server-to-server copy by default
Message-ID: <20211022125835.GA11434@fieldses.org>
References: <20211020155421.GC597@fieldses.org>
 <18E32DF5-3F1D-4C23-8C2F-A7963103CF8C@oracle.com>
 <CAN-5tyEL4L2GH=-MDGS4qNTcCLRPFCQzfDQjFAVbG7wMKvHxOg@mail.gmail.com>
 <8b1eb564-974d-00b6-397a-d92f301df7d8@oracle.com>
 <20211020202907.GF597@fieldses.org>
 <a009cbf3-cb83-b7c8-aa86-2eee06962b68@oracle.com>
 <20211021140243.GB25711@fieldses.org>
 <78839450-8095-01ae-53e8-f0ebf941b5a5@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <78839450-8095-01ae-53e8-f0ebf941b5a5@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Thu, Oct 21, 2021 at 11:34:44PM -0700, dai.ngo@oracle.com wrote:
> On 10/21/21 7:02 AM, Bruce Fields wrote:
> >Thanks for the persistence:
> >
> >On Wed, Oct 20, 2021 at 10:00:41PM -0700, dai.ngo@oracle.com wrote:
> >>The attack can come from the replies of the source server or requests
> >>from the source server to the destination server via the back channel.
> >>One of possible attack in the reply is BAD_STATEID which was handled
> >>by the client code as mentioned by Olga.
> >>
> >>Here is the list of NFS requests made from the destination to the
> >>source server:
> >>
> >>         EXCHANGE_ID
> >>         CREATE_SESSION
> >>         RECLAIM_COMLETE
> >>         SEQUENCE
> >>         PUTROOTFH
> >>         PUTHF
> >>         GETFH
> >>         GETATTR
> >>         READ/READ_PLUS
> >>         DESTROY_SESSION
> >>         DESTROY_CLIENTID
> >>
> >>Do you think we should review all replies from these requests to make
> >>sure error replies do not cause problems for the destination server?
> >That's the exactly the sort of analysis I was curious to see, yes.
> 
> I will go through these requests to see if is there is anything that
> we need to do to ensure the destination does not react negatively
> on the replies.
> 
> >
> >(I doubt the PUTROOTFH, PUTFH, GETFH, and GETATTR are really necessary,
> >I wonder if there's any way we could just bypass them in our case.  I
> >don't know, maybe that's more trouble than it's worth.)
> 
> I'll take a look but I think we should avoid modifying the client
> code if possible.
> 
> >
> >>same for the back channel ops:
> >>
> >>         OP_CB_GETATTR
> >>         OP_CB_RECALL
> >>         OP_CB_LAYOUTRECALL
> >>         OP_CB_NOTIFY
> >>         OP_CB_PUSH_DELEG
> >>         OP_CB_RECALL_ANY
> >>         OP_CB_RECALLABLE_OBJ_AVAIL
> >>         OP_CB_RECALL_SLOT
> >>         OP_CB_SEQUENCE
> >>         OP_CB_WANTS_CANCELLED
> >>         OP_CB_NOTIFY_LOCK
> >>         OP_CB_NOTIFY_DEVICEID
> >>         OP_CB_OFFLOAD
> >There shouldn't be any need for callbacks at all.  We might be able to
> >get away without even setting up a backchannel.  But, yes, if the server
> >tries to send one anyway, it'd be good to know we do something
> >reasonable.
> 
> or do not specify the back channel when creating the session somehow.
> I will report back.

Thank you, Dai!

--b.