From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ganesha.gnumonks.org (ganesha.gnumonks.org [213.95.27.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE5771EB39 for ; Mon, 1 Jul 2024 20:30:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.27.120 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719865836; cv=none; b=Xb7SOA6zbFctMSNc+vRaScsQ0AVM9bIRiL7Dz1XmT+sTWBYYY9Tu5gskgqOFrtpBbz5R7xPMxlNGu9CljQH0Is8jFZtxiNpjXNebOs11prnj0v85ahIYw5mTutdFaqyvQJkgWKIPvqMTpryiwcMLCUM02F4kAhUbP5Fn486RnWU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719865836; c=relaxed/simple; bh=69dkv+qri4zylHzCik7IwRQKCdEzGWnKwr3k2T18zXg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Hg2PGIujbeJoNfchyrjEGDehUSlTSE/wkfhEfeUWTvtnBhdI5rKkcTavfXnDLQ6P1Adrk1esbKB0aw3pgsfu9lZNp0q3wq7psjmoeVWcOLeZ2m/CX/aNxufw6eKimP6fMy7tuQ9hcefINFq3iCLnVbmphnySqK2fkEq2l9b0dtg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=netfilter.org; spf=pass smtp.mailfrom=gnumonks.org; arc=none smtp.client-ip=213.95.27.120 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=netfilter.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gnumonks.org Received: from [31.221.216.127] (port=3012 helo=gnumonks.org) by ganesha.gnumonks.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sONfG-00HLR4-RB; Mon, 01 Jul 2024 22:30:21 +0200 Date: Mon, 1 Jul 2024 22:30:17 +0200 From: Pablo Neira Ayuso To: Florian Westphal Cc: netfilter-devel@vger.kernel.org Subject: Re: [RFC nf-next 3/4] netfilter: nf_tables: insert register zeroing instructions for dodgy chains Message-ID: References: <20240627135330.17039-1-fw@strlen.de> <20240627135330.17039-4-fw@strlen.de> Precedence: bulk X-Mailing-List: netfilter-devel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240627135330.17039-4-fw@strlen.de> X-Spam-Score: -1.9 (-) On Thu, Jun 27, 2024 at 03:53:23PM +0200, Florian Westphal wrote: > Instead of rejecting rules that read from registers that saw no store, > insert nft_imm instruction preamble when building the ruleset blob. > > Once any rule triggers 'uninitied access', table gets marked as > need-rebuild, then all base-chains in the affected table are regenerated. > > Known drawback: 'nft monitor trace' may show 'unkown rule handle 0 > verdict continue' when this auto-zero is active. > If this is unwanted, the trace infra in kernel could be patched to > suppress notification for handle-0 rules. > > As normal rulesets generated by nft or iptables-nft never cause such > uninitialised reads this allows to revert the forced zeroing in the > next patch. > > I would not add this patch and keep the reject behaviour, as the > nftables uapi is specifically built around the rule being a standalone > object. I also question if it makes real sense to do such preload from > userspace, it has little benefit for well-formed (non-repetitive) rulesets. I am afraid there won't be an easy way to revert this in this future? Is there any specific concern you have? Buggy validation allowing to access uninitialized registers? In that case, there is a need to improve test infrastructure to exercise this code more. Thanks.