From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5784C433ED for ; Mon, 17 May 2021 15:34:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9948761004 for ; Mon, 17 May 2021 15:34:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242684AbhEQPfS (ORCPT ); Mon, 17 May 2021 11:35:18 -0400 Received: from mx2.suse.de ([195.135.220.15]:52508 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244705AbhEQPdB (ORCPT ); Mon, 17 May 2021 11:33:01 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1621265504; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D78x0RQykGxtuFVKDLK2tegONNqQIINNV1fp5HE+u1o=; b=UlpURxft8mCNp5WtrDPvtUpGOpEsRnDR0jJF0c7mh+vDsIm6ScJ7qTGjqT60UiVDQRJ6k0 41KGiWtA9xdJD4l8MO7kltHMJ9fUX+Dq08VZR9dbQatXEsB9+Cf/xLGKQnaKCC2nOvEHGu Hwt42g0mrif5bw2UWDSVartMsW1ZQPg= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4AAFDB038; Mon, 17 May 2021 15:31:44 +0000 (UTC) Subject: Re: [PATCH 7/8] xen/netfront: don't trust the backend response data blindly To: Juergen Gross Cc: Boris Ostrovsky , Stefano Stabellini , "David S. Miller" , Jakub Kicinski , xen-devel@lists.xenproject.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210513100302.22027-1-jgross@suse.com> <20210513100302.22027-8-jgross@suse.com> From: Jan Beulich Message-ID: <18aa307e-edf0-cb8b-1fd2-2b5c89522d02@suse.com> Date: Mon, 17 May 2021 17:31:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210513100302.22027-8-jgross@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 13.05.2021 12:03, Juergen Gross wrote: > @@ -429,6 +453,12 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue) > } while (more_to_do); > > xennet_maybe_wake_tx(queue); > + > + return; > + > + err: > + queue->info->broken = true; > + dev_alert(dev, "Disabled for further use\n"); > } If in blkfront the ability to revive a device via a suspend/resume cycle is "a nice side effect", wouldn't it be nice for all frontends to behave similarly in this regard? I.e. wouldn't you want to also clear this flag somewhere? And shouldn't additionally / more generally a disconnect / connect cycle allow proper operation again? > @@ -472,6 +502,13 @@ static void xennet_tx_setup_grant(unsigned long gfn, unsigned int offset, > > *tx = info->tx_local; > > + /* > + * The request is not in its final form, as size and flags might be > + * modified later, but even if a malicious backend will send a response > + * now, nothing bad regarding security could happen. > + */ > + queue->tx_pending[id] = true; I'm not sure I can agree with what the comment says. If the backend sent a response prematurely, wouldn't the underlying slot(s) become available for re-use, and hence potentially get filled / updated by two parties? Jan