On Tue, Jul 02, 2024 at 12:18:30AM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > 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. > > Yes, for one thing, but I also do not see how we can ever move to a > model where registers are re-used by subsequent rules, its incompatible > with the rule-is-smallest-replaceable-object design. Yes, incremental updates are an issue. Another possibility is to add support for static rulesets, so there is a simple way for userspace to recycle registers (this would be fully performed from userspace). And users can still inject raw bytecode to make their own programs. We have been discussing that dumping a listing with bytecode that cannot be interpreted is an option to deal with "forward compatibility", similar approach could help deal with this. If your concern is the register tracking from the kernel, I am not pursuing that approach anymore and I can make a patch to ditch it after this series. > (Meaning: userspace needs to be fully cooperative and aware that > it cannot insert a random rule at location x).
