Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB321C54EAA for ; Fri, 27 Jan 2023 14:17:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232367AbjA0ORz (ORCPT ); Fri, 27 Jan 2023 09:17:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229898AbjA0ORv (ORCPT ); Fri, 27 Jan 2023 09:17:51 -0500 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 814164EE1 for ; Fri, 27 Jan 2023 06:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674829070; x=1706365070; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=YSLo2Eg7xACX5j9lFrWlTXd/5fp84SzG0tsDWpLVJ/Y=; b=e7PTPfq5VhR2+oFc3XQ+88ZFGKiCRhklIjYf3lfWpLnslVNnGUFeS+Ce o51rrvqcyYPFEGG8npUW/l1bhtnLIaMsshTdSpfHni/HwAKwgOZF66laR qMsugTPiSyjM/7jaLSI0aITZG2WiKU57809ub8lTvG+mNy5rSF2gVjWeg Kwz+lGGkXo9VNye+65c4PWgb264ve87xg7zyDgVMIZoloCTZbTjRHAAEs Vo7Y8b045Y6VobNGg/IOs2IrICvO/Daal570kcdA3NYgM6MInYmCDYUVP ZlkHVZSryfnT7234IRP6eu88MBlGcJjCFF824T2apYtgKcsqzAlIDK5e0 A==; X-IronPort-AV: E=McAfee;i="6500,9779,10602"; a="307437888" X-IronPort-AV: E=Sophos;i="5.97,251,1669104000"; d="scan'208";a="307437888" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2023 06:17:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10602"; a="665270926" X-IronPort-AV: E=Sophos;i="5.97,251,1669104000"; d="scan'208";a="665270926" Received: from ubik.fi.intel.com (HELO localhost) ([10.237.72.184]) by fmsmga007.fm.intel.com with ESMTP; 27 Jan 2023 06:17:46 -0800 From: Alexander Shishkin To: Greg Kroah-Hartman Cc: "Michael S. Tsirkin" , jasowang@redhat.com, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, elena.reshetova@intel.com, kirill.shutemov@linux.intel.com, Andi Kleen , Amit Shah , Arnd Bergmann , alexander.shishkin@linux.intel.com Subject: Re: [PATCH v1 2/6] virtio console: Harden port adding In-Reply-To: References: <20230119135721.83345-1-alexander.shishkin@linux.intel.com> <20230119135721.83345-3-alexander.shishkin@linux.intel.com> <87ilh2quto.fsf@ubik.fi.intel.com> <87a62eqo4h.fsf@ubik.fi.intel.com> <20230127055944-mutt-send-email-mst@kernel.org> <87k018p4xs.fsf@ubik.fi.intel.com> <20230127071152-mutt-send-email-mst@kernel.org> <87edrgp2is.fsf@ubik.fi.intel.com> Date: Fri, 27 Jan 2023 16:17:46 +0200 Message-ID: <87bkmkoyd1.fsf@ubik.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Greg Kroah-Hartman writes: > On Fri, Jan 27, 2023 at 02:47:55PM +0200, Alexander Shishkin wrote: >> "Michael S. Tsirkin" writes: >> >> > On Fri, Jan 27, 2023 at 01:55:43PM +0200, Alexander Shishkin wrote: >> >> We can have shared pages between the host and guest without bounce >> >> buffers in between, so they can be both looking directly at the same >> >> page. >> >> >> >> Regards, >> > >> > How does this configuration work? What else is in this page? >> >> So, for example in TDX, you have certain pages as "shared", as in >> between guest and hypervisor. You can have virtio ring(s) in such >> pages. It's likely that there'd be a swiotlb buffer there instead, but >> sharing pages between host virtio and guest virtio drivers is possible. > > If it is shared, then what does this mean? Do we then need to copy > everything out of that buffer first before doing anything with it > because the data could change later on? Or do we not trust anything in > it at all and we throw it away? Or something else (trust for a short > while and then we don't?) The first one, we need a consistent view of the metadata (the ckpt in this case), so we take a snapshot of it. Then, we validate it (because we don't trust it) to be correct. If it is not, we discard it, otherwise we act on it. Since this is a ring, we just move on to the next record if there is one. Meanwhile, in the shared page, it can change from correct to incorrect, but it won't affect us because we have this consistent view at the moment the snapshot was taken. > Please be specific as to what you want to see happen here, and why. For example, if we get a control message to add a port and cpkt->event==PORT_ADD, we skip validation of cpkt->id (port id), because we're intending to add a new one. At this point, the device can change cpkt->event to PORT_REMOVE, which does require a valid cpkt->id and the subsequent code runs into a NULL dereference on the port value, which should have been looked up from cpkt->id. Now, if we take a snapshot of cpkt, we naturally don't have this problem, because we're looking at a consistent state of cpkt: it's either PORT_ADD or PORT_REMOVE all the way. Which is what this patch does. Does this answer your question? Thanks, -- Alex