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;
Message-ID: <e49873a0-634c-a954-14f6-af111b5d6adc@oracle.com>
Date:   Mon, 1 Nov 2021 12:55:46 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.2.1
Subject: Re: server-to-server copy by default
Content-Language: en-US
To:     Bruce Fields <bfields@fieldses.org>
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>
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>
 <1500403d-6aa1-3909-d44f-b33c1c1f3ce2@oracle.com>
 <20211101193346.GD14427@fieldses.org>
From:   dai.ngo@oracle.com
In-Reply-To: <20211101193346.GD14427@fieldses.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Zk5lc2VhSk5JaDFqSmZzVmhxUnBmUmYwOThuN080YXNybjZOUFdOUGQ0ZnZv?=
 =?utf-8?B?aTVkckJDSmJzYWs2RTdTcGIxTklIQkVTVFRLOC82WDNDSEY1bHZjQjczek9N?=
 =?utf-8?B?RnlCZ1ZuK3dqZ3ltdDZrZ1NRbFZyRURzd081a25EeXArWDU4cXU1ak84U1Fj?=
 =?utf-8?B?ZS9ldjFrajM2eWFST0pKSGFmcmpKN3hmL1B3VUk4NUVqSU5yOW1KTFAyNVdM?=
 =?utf-8?B?emlzaHFMbVo0eXRwQ2VwbzI0KzJoSkp4TGE5U1dJSjBJQmlRNXhsNXJlNlVm?=
 =?utf-8?B?WnJNVmY4MUVzV3NOS2RsNlpVdkN2bFYycmNsQ2xVQ29OTU5lWEtXbmZnUFQv?=
 =?utf-8?B?eVdmQjFWeXE4enFmMXZXT08zbUJaVC8zbEVENkVzSEhoS3FsTWRIUEwxYUZY?=
 =?utf-8?B?Q2hKV21CbGQyZXZOb1FTRStSZ0pabW5jVVRjN01ITU96WGVKay9UR3VxQ2tq?=
 =?utf-8?B?Q3J4VGlaU1RBRFJZYUpRSW0yNnF1bUduZ08xL1FZdkxDcllHMHF2ZkxxcWZa?=
 =?utf-8?B?WTZMUm55dVJZbm9LeVN6QlJ0M0ZYOHBwdkJHeUh0cG9RNWphTEs5Sk1tYVVx?=
 =?utf-8?B?UkE4cnoxOTJ3b1VJcnZRN3I4V0JDTW5lZlVYc0hwMnozbElMTGJiR3ZiWTEw?=
 =?utf-8?B?T3haQWE1dnZOWVptZ3dJSUQ0T0VBUkVQcmQ4dzh3cE5BZE04Ynp3bW5DaUdQ?=
 =?utf-8?B?dDJDdkxTWVhRNG5RU21JV3JXR2FFTWlWOGRyclAyZUdJTnhnR2VXRFpYbmtj?=
 =?utf-8?B?aEJNUVZ5ekZxblUyK1laVndva0FaTWxDR0R1L0pmdGg2Yjh0OS84WjU5bzBK?=
 =?utf-8?B?RHEzcU1HTkJhS0djOUoyZmVMdnJhaW5jZHI5NUVvYUNwazg5WG5ETU1ERi9V?=
 =?utf-8?B?MHE1SkdCSm1VYjlNa2VRek5vT2VMcXJ5dEkvVmRSRzNtbHVaY3pmcFlPTFMz?=
 =?utf-8?B?ZHpVZEdjY1g2YzdaVjRNTWxGWEZZeDhXQ1Izc3YrbE5ack9HbHNqVlYvM0F6?=
 =?utf-8?B?MVBRZUZVa0h3TkNqMW9NK0hZUzBINHhEaWw1aGkwSjNtYllSL2ZXRGJtZEM2?=
 =?utf-8?B?aWJrU2JvOXZaaE4rUEExclJXd2J4d0t5WjU1NW0rVVdiR1E0RjJjenJ5THZZ?=
 =?utf-8?B?UjFSanVZVjdVRUllQjBYUGYybElOcTZvM0s0R09BV3g0dU4vNnVQOTNsQ2VX?=
 =?utf-8?B?a01OQjhyM2tRV2M2S21DdnV0ck9HdFdJeWgzdFZMNkJ4YlRYMi9mN3NhR2o4?=
 =?utf-8?B?K2xoYVVjQjRiR0JIdXFCbkNoNkhUMUhkNGF6Wm1PUkF0elFNZ0YvK3dtMHJj?=
 =?utf-8?B?dkxrVU1BZ3BPaE5adXNWaXRqa0NJQ1ljbG5kYnVuT204UzFYMGtBZHVZSGN0?=
 =?utf-8?B?bWVhVmJPc210VFhrMDNxN0diMGRLTmVSSnE5YUZxTUJ4WGtTT25pbHVhelYx?=
 =?utf-8?B?TXhHRTJDWTJTQjlzY2JYbkpBOGE0TEhkVnk4R1hZK0tjTElyYndjZWZHSUxC?=
 =?utf-8?B?cFAwVDlnRytrcHNuZEkxbTFGNWpWKzN6M1BrTjg3TDcrRUtiV1JCTHZlRHVj?=
 =?utf-8?B?ZHpVdUdoM2JUUkhjNEFOcGprcnBuVmprRno5WG90aVFQVkJkbDdJYU5CUWtE?=
 =?utf-8?B?VGgzVW1uNVNldWZZS0ZLbTFsYzlZOEdkeGVsME9pMG1sTmRINFQ0QmhmNDg2?=
 =?utf-8?B?M1hiNEFqUkdLKzNUcVU4Qm1mOXcyYUF4WVJKaWdlcXY4MWlhRVQzbnV1VzZu?=
 =?utf-8?B?R0FCK0t2Q3I4dGNlRE42U2ZybE1MQ3BSN3F6Tk9BekZCVjlRQ0JWcGtoejlN?=
 =?utf-8?B?NmxrVUowd1preWkzSkJiVHRRWFkrZTM1cUpUZEdjdithM3RLREtDSDNvaUxL?=
 =?utf-8?B?VW9NR3NIMXYxWkt1ZjVDTWhqT0pJTVJURGQ5SExyYVZ0YUZBbnJWQWF4TnlW?=
 =?utf-8?B?RGlQMGg0SnUrWWRxMjc5d0QrdjlPd20zVjdsNDNTL1BPZEMwT0pBQkZ1bm41?=
 =?utf-8?B?WVdybC92blVzMWpFbFZMRGMrbFlYcEVXcFFhYURKUE1SazVkTFJOd3ZySUwx?=
 =?utf-8?B?ZHQvblArb2xGK1hVNVc3dlh3UU5YV3IyZkJKMmF4NVRTdGpzLytkeTBFRGZK?=
 =?utf-8?B?SmZVT1ovQnY1U2pPaHJzYWdtYXh6NVNQVHdMaGk1TmtvQXRkdTRRN1VHVCt2?=
 =?utf-8?Q?n2HnGXab1CdGUWYTWN0xToA=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a50ba012-c134-4303-a8a5-08d99d719b4c
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4257.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2021 19:55:51.3297
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: mqVQDmn/3a7pkRo1n1O5SR475kXsv/UP2PsHTSn4uhK/mAJmo/mUhlAiTb36TQkWhHsfXaZp1+6NRory0ZROVw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3032
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10155 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 spamscore=0
 malwarescore=0 mlxlogscore=999 adultscore=0 phishscore=0 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000
 definitions=main-2111010105
X-Proofpoint-GUID: i-RrT-2SoR4_GXBqVxQ5mwRTArKe9lut
X-Proofpoint-ORIG-GUID: i-RrT-2SoR4_GXBqVxQ5mwRTArKe9lut
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


On 11/1/21 12:33 PM, Bruce Fields wrote:
> On Mon, Nov 01, 2021 at 10:37:11AM -0700, dai.ngo@oracle.com wrote:
>> On 10/21/21 11:34 PM, dai.ngo@oracle.com wrote:
>>> On 10/21/21 7:02 AM, Bruce Fields wrote:
>>>> 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.
>> still need to be done.
>>
>>>> (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.
>> We can not disable the back channel of the SSC v4.2 mount since it might
>> share the same connection with a regular NFSv4.2 mount from the destination
>> to the source server.
> Hm.
>
> Well, now that I think of it, a backchannel is probably required for the
> SSC case anyway.  (I think CB_RECALL_SLOT is mandatory to support?)

I think the back channel is not required. From Sec 13 of RFC 7862:

    The REQUIRED or OPTIONAL designation for callback operations sent by
    the server is for both the client and server.  Generally, the client
    has the option of creating the backchannel and sending the operations
    on the forechannel that will be a catalyst for the server sending
    callback operations.  A partial exception is CB_RECALL_SLOT; the only
    way the client can avoid supporting this operation is by not creating
    a backchannel.

I have not found a clean/simple way to not creating the back channel
for the SSC mount. The reasons is that the SSC mount can be using an
existing connection of a regular mount to the source server, or a
regular mount can happen after the SSC mount.

It seems that we should support back channel for SSC mount but do a
due diligent check to make sure the requests come from a trusted source
and also limit the number of ops supported on the SSC back channel.

-Dai

>
> --b.