On Thu, Oct 17, 2024 at 03:33:14PM -0400, Paul Moore wrote:
> > On Wed, Oct 16, 2024 at 06:10:44PM +0200, Florian Westphal wrote:
> For those of us joining the conversation late, can you provide a quick
> summary of what you want to change in audit and why?
Florian said:
"I failed to realize that nft_audit leaks one implementation detail
to userspace: the length of the transaction log."
table=t1 family=2 entries=4 op=nft_register_set
He is referring to the 'entries' key.
So far, every object gets one transaction, but now batching several
objects in one transaction is possible.
We have been discussing what the expected semantics for this audit log
key is:
- If this is the transaction log length, then the internal update of the
transaction logic results in a smaller number of 'entries' in the
audit log.
- If 'entries' refers to the number of "affected" objects by this
operation, then this means we have to carry a "workaround" in
the kernel.
This is because:
1) Element updates are now supported, this currently handles it as a
_REGISTER operation according to enum audit_nfcfgop. This changed
the semantics of the add command, now it is "add if it does not exist,
otherwise update what it already exists". Before, updates where simply
elided (not counted by 'entries' key) because they were not supported.
That is, 'entries' now tell how many set element has been added OR
updated. I think this is fine, this is consistent with chain updates
where 'entries' also report added OR updated chains. The difference
is that old kernel do not count updates (because they are elided).
2) There is ongoing work to add more internal transaction batching, ie.
use one single transaction for several elements. This requires a
special case to bump the 'entries' key to add the elements that the
transaction batch contains, see:
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20241016131917.17193-4-fw@xxxxxxxxx/
There is a nft_audit.sh selftest and Florian thinks this is a
"workaround" patch only to make this test happy, because 'entries'
refers to the transaction log length (which is now smaller given the
internal transaction batching approach to accumulate several elements
is used).
