On Tue, Apr 25, 2023 at 08:51:43PM +0100, Jeremy Sowden wrote:
> On 2023-04-12, at 13:06:02 +0200, Pablo Neira Ayuso wrote:
> > On Tue, Apr 11, 2023 at 01:21:40PM +0100, Jeremy Sowden wrote:
> > > On 2023-03-26, at 22:39:42 +0200, Pablo Neira Ayuso wrote:
> > > > Jeremy, may I suggest you pick up on the bitwise _SREG2 support?
> > > > I will post a v4 with small updates for ("mark statement support
> > > > for non-constant expression") tomorrow. Probably you don't need
> > > > the new AND and OR operations for this? Only the a new _SREG2 to
> > > > specify that input comes from non-constant?
> > >
> > > Just to clarify, do you want just the `_SREG2` infrastructure from
> > > the last patch series but without the new bitwise ops? That is to
> > > say it would be possible to send two operands to the kernel in
> > > registers, but no use would be made of it (yet). Or are you
> > > proposing to update the existing mask-and-xor ops to send right hand
> > > operands via registers?
> >
> > I mean, would it be possible to add a NFT_BITWISE_BOOL variant that
> > takes _SREG2 via select_ops?
>
> In an earlier version, instead of adding new boolean ops, I added
> support for passing the mask and xor arguments in registers:
>
> https://lore.kernel.org/netfilter-devel/20200224124931.512416-1-jeremy@xxxxxxxxxx/
>
> Doing the same thing with one extra register is straightforward for AND
> and XOR:
>
> AND(x, y) = (x & y) ^ 0
> XOR(x, y) = (x & 1) ^ y
>
> since we can pass y in _SREG2 and 0 in _XOR for AND, and 1 in _MASK and
> y in _SREG2 for XOR. For OR:
>
> OR(x, y) = (x & ~y) ^ y
>
> it's a bit more complicated. Instead of getting both the mask and xor
> arguments from user space, we need to do something like passing y in
> _SREG2 alone, and then constructing the bitwise negation in the kernel.
>
> Obviously, this means that the kernel is no longer completely agnostic
> about the sorts of mask-and-xor expressions user space may send.
>
> Since that is the case, we could go further and just perform the
> original ope- rations. Thus if we get an boolean op with an _SREG2
> argument:
>
> * if there is an _XOR of 0, compute:
>
> _SREG & _SREG2
>
> * if there is a _MASK of 1, compute:
>
> _SREG ^ _SREG2
>
> * if there are no _MASK or _XOR arguments, compute:
>
> _SREG | _SREG2
OK, if my understanding is correct, these are the two options:
1) Infer from arguments the type of operation.
2) Have explicit NFT_BITWISE_{AND,OR,XOR} operations.
If so, I think it is better to stick to your original patch, where
explicit bitwise operations NFT_BITWISE_{_AND,_OR,_XOR} are added
(which is what you proposed last time IIRC).
Thanks for explaining.
