[PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[valis]

Three classifiers (cls_fw, cls_u32 and cls_route) always copy 
tcf_result struct into the new instance of the filter on update.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the 
success path, decreasing filter_cnt of the still referenced class 
and allowing it to be deleted, leading to a use-after-free.

This patch set fixes this issue in all affected classifiers by no longer
copying the tcf_result struct from the old filter.

valis (3):
  net/sched: cls_u32: No longer copy tcf_result on update to avoid
    use-after-free
  net/sched: cls_fw: No longer copy tcf_result on update to avoid
    use-after-free
  net/sched: cls_route: No longer copy tcf_result on update to avoid
    use-after-free

 net/sched/cls_fw.c    | 1 -
 net/sched/cls_route.c | 1 -
 net/sched/cls_u32.c   | 1 -
 3 files changed, 3 deletions(-)

-- 
2.30.2

[PATCH net 1/3] net/sched: cls_u32: No longer copy tcf_result on update to avoid use-after-free

[valis]

When u32_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the 
success path, decreasing filter_cnt of the still referenced class 
and allowing it to be deleted, leading to a use-after-free.

Fix this by no longer copying the tcf_result struct from the old filter.

Fixes: de5df63228fc ("net: sched: cls_u32 changes to knode must appear atomic to readers")
Reported-by: valis <sec@valis.email>
Reported-by: M A Ramdhan <ramdhan@starlabs.sg>
Signed-off-by: valis <sec@valis.email>
Cc: stable@vger.kernel.org
---
 net/sched/cls_u32.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index 5abf31e432ca..19aa60d1eea7 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -826,7 +826,6 @@ static struct tc_u_knode *u32_init_knode(struct net *net, struct tcf_proto *tp,
 
 	new->ifindex = n->ifindex;
 	new->fshift = n->fshift;
-	new->res = n->res;
 	new->flags = n->flags;
 	RCU_INIT_POINTER(new->ht_down, ht);
 
-- 
2.30.2

[PATCH net 2/3] net/sched: cls_fw: No longer copy tcf_result on update to avoid use-after-free

[valis]

When fw_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the 
success path, decreasing filter_cnt of the still referenced class 
and allowing it to be deleted, leading to a use-after-free.

Fix this by no longer copying the tcf_result struct from the old filter.

Fixes: e35a8ee5993b ("net: sched: fw use RCU")
Reported-by: valis <sec@valis.email>
Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Signed-off-by: valis <sec@valis.email>
Cc: stable@vger.kernel.org
---
 net/sched/cls_fw.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c
index 8641f8059317..c49d6af0e048 100644
--- a/net/sched/cls_fw.c
+++ b/net/sched/cls_fw.c
@@ -267,7 +267,6 @@ static int fw_change(struct net *net, struct sk_buff *in_skb,
 			return -ENOBUFS;
 
 		fnew->id = f->id;
-		fnew->res = f->res;
 		fnew->ifindex = f->ifindex;
 		fnew->tp = f->tp;
 
-- 
2.30.2

[PATCH net 3/3] net/sched: cls_route: No longer copy tcf_result on update to avoid use-after-free

[valis]

When route4_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the 
success path, decreasing filter_cnt of the still referenced class 
and allowing it to be deleted, leading to a use-after-free.

Fix this by no longer copying the tcf_result struct from the old filter.

Fixes: 1109c00547fc ("net: sched: RCU cls_route")
Reported-by: valis <sec@valis.email>
Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Signed-off-by: valis <sec@valis.email>
Cc: stable@vger.kernel.org
---
 net/sched/cls_route.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/sched/cls_route.c b/net/sched/cls_route.c
index d0c53724d3e8..1e20bbd687f1 100644
--- a/net/sched/cls_route.c
+++ b/net/sched/cls_route.c
@@ -513,7 +513,6 @@ static int route4_change(struct net *net, struct sk_buff *in_skb,
 	if (fold) {
 		f->id = fold->id;
 		f->iif = fold->iif;
-		f->res = fold->res;
 		f->handle = fold->handle;
 
 		f->tp = fold->tp;
-- 
2.30.2

Re: [PATCH net 1/3] net/sched: cls_u32: No longer copy tcf_result on update to avoid use-after-free

[M A Ramdhan]

On Sat, Jul 22, 2023 at 12:51 AM valis <sec@valis.email> wrote:
>
> When u32_change() is called on an existing filter, the whole
> tcf_result struct is always copied into the new instance of the filter.
>
> This causes a problem when updating a filter bound to a class,
> as tcf_unbind_filter() is always called on the old instance in the
> success path, decreasing filter_cnt of the still referenced class
> and allowing it to be deleted, leading to a use-after-free.
>
> Fix this by no longer copying the tcf_result struct from the old filter.
>
> Fixes: de5df63228fc ("net: sched: cls_u32 changes to knode must appear atomic to readers")
> Reported-by: valis <sec@valis.email>
> Reported-by: M A Ramdhan <ramdhan@starlabs.sg>
> Signed-off-by: valis <sec@valis.email>
> Cc: stable@vger.kernel.org
> ---
>  net/sched/cls_u32.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
> index 5abf31e432ca..19aa60d1eea7 100644
> --- a/net/sched/cls_u32.c
> +++ b/net/sched/cls_u32.c
> @@ -826,7 +826,6 @@ static struct tc_u_knode *u32_init_knode(struct net *net, struct tcf_proto *tp,
>
>         new->ifindex = n->ifindex;
>         new->fshift = n->fshift;
> -       new->res = n->res;
>         new->flags = n->flags;
>         RCU_INIT_POINTER(new->ht_down, ht);
>
> --
> 2.30.2
>
Hi,

We also thought it's also the correct fixes,
but we're not sure because it will always remove the already bound
qdisc class when we change the filter, even tho we never specify
the new TCA_U32_CLASSID in the new filter.

I also look at the implementation of cls_tcindex and cls_rsvp which still copy
the old tcf_result, but don't call the tcf_unbind_filter when changing
the filter.

If it's the intended behaviour, then I'm good with this patch.

Thanks & Regards,
M A Ramdhan

Re: [PATCH net 1/3] net/sched: cls_u32: No longer copy tcf_result on update to avoid use-after-free

[Pedro Tammela]

On 21/07/2023 15:04, M A Ramdhan wrote:
> On Sat, Jul 22, 2023 at 12:51 AM valis <sec@valis.email> wrote:
>>
>> When u32_change() is called on an existing filter, the whole
>> tcf_result struct is always copied into the new instance of the filter.
>>
>> This causes a problem when updating a filter bound to a class,
>> as tcf_unbind_filter() is always called on the old instance in the
>> success path, decreasing filter_cnt of the still referenced class
>> and allowing it to be deleted, leading to a use-after-free.
>>
>> Fix this by no longer copying the tcf_result struct from the old filter.
>>
>> Fixes: de5df63228fc ("net: sched: cls_u32 changes to knode must appear atomic to readers")
>> Reported-by: valis <sec@valis.email>
>> Reported-by: M A Ramdhan <ramdhan@starlabs.sg>
>> Signed-off-by: valis <sec@valis.email>
>> Cc: stable@vger.kernel.org
>> ---
>>   net/sched/cls_u32.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
>> index 5abf31e432ca..19aa60d1eea7 100644
>> --- a/net/sched/cls_u32.c
>> +++ b/net/sched/cls_u32.c
>> @@ -826,7 +826,6 @@ static struct tc_u_knode *u32_init_knode(struct net *net, struct tcf_proto *tp,
>>
>>          new->ifindex = n->ifindex;
>>          new->fshift = n->fshift;
>> -       new->res = n->res;
>>          new->flags = n->flags;
>>          RCU_INIT_POINTER(new->ht_down, ht);
>>
>> --
>> 2.30.2
>>
> Hi,
> 
> We also thought it's also the correct fixes,
> but we're not sure because it will always remove the already bound
> qdisc class when we change the filter, even tho we never specify
> the new TCA_U32_CLASSID in the new filter.

The user should always explicitly tell the classid. Some other 
classifiers are already behaving like this, these were just wrong.

> 
> I also look at the implementation of cls_tcindex and cls_rsvp which still copy
> the old tcf_result, but don't call the tcf_unbind_filter when changing
> the filter.

Both were deprecated and removed as they were beyond saving.

> 
> If it's the intended behaviour, then I'm good with this patch.
> 
> Thanks & Regards,
> M A Ramdhan

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[Pedro Tammela]

On 21/07/2023 14:48, valis wrote:
> Three classifiers (cls_fw, cls_u32 and cls_route) always copy
> tcf_result struct into the new instance of the filter on update.
> 
> This causes a problem when updating a filter bound to a class,
> as tcf_unbind_filter() is always called on the old instance in the
> success path, decreasing filter_cnt of the still referenced class
> and allowing it to be deleted, leading to a use-after-free.
> 
> This patch set fixes this issue in all affected classifiers by no longer
> copying the tcf_result struct from the old filter.
> 
> valis (3):
>    net/sched: cls_u32: No longer copy tcf_result on update to avoid
>      use-after-free
>    net/sched: cls_fw: No longer copy tcf_result on update to avoid
>      use-after-free
>    net/sched: cls_route: No longer copy tcf_result on update to avoid
>      use-after-free
> 
>   net/sched/cls_fw.c    | 1 -
>   net/sched/cls_route.c | 1 -
>   net/sched/cls_u32.c   | 1 -
>   3 files changed, 3 deletions(-)
> 

For the series,

Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
Tested-by: Pedro Tammela <pctammela@mojatatu.com>

Re: [PATCH net 1/3] net/sched: cls_u32: No longer copy tcf_result on update to avoid use-after-free

[Jamal Hadi Salim]

On Fri, Jul 21, 2023 at 2:05 PM M A Ramdhan <ramdhan@starlabs.sg> wrote:
>
> On Sat, Jul 22, 2023 at 12:51 AM valis <sec@valis.email> wrote:
> >
> > When u32_change() is called on an existing filter, the whole
> > tcf_result struct is always copied into the new instance of the filter.
> >
> > This causes a problem when updating a filter bound to a class,
> > as tcf_unbind_filter() is always called on the old instance in the
> > success path, decreasing filter_cnt of the still referenced class
> > and allowing it to be deleted, leading to a use-after-free.
> >
> > Fix this by no longer copying the tcf_result struct from the old filter.
> >
> > Fixes: de5df63228fc ("net: sched: cls_u32 changes to knode must appear atomic to readers")
> > Reported-by: valis <sec@valis.email>
> > Reported-by: M A Ramdhan <ramdhan@starlabs.sg>
> > Signed-off-by: valis <sec@valis.email>
> > Cc: stable@vger.kernel.org
> > ---
> >  net/sched/cls_u32.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
> > index 5abf31e432ca..19aa60d1eea7 100644
> > --- a/net/sched/cls_u32.c
> > +++ b/net/sched/cls_u32.c
> > @@ -826,7 +826,6 @@ static struct tc_u_knode *u32_init_knode(struct net *net, struct tcf_proto *tp,
> >
> >         new->ifindex = n->ifindex;
> >         new->fshift = n->fshift;
> > -       new->res = n->res;
> >         new->flags = n->flags;
> >         RCU_INIT_POINTER(new->ht_down, ht);
> >
> > --
> > 2.30.2
> >
> Hi,
>
> We also thought it's also the correct fixes,
> but we're not sure because it will always remove the already bound
> qdisc class when we change the filter, even tho we never specify
> the new TCA_U32_CLASSID in the new filter.

I am assuming you are referring to the u32 classifier here and from
what you are describing you first create a filter with reference to an
existing class and then you replace it to not reference the class - am
i correct? If yes, then please provide an example policy setup? We
tested this scenario on u32 extensively and it should be fine.

cheers,
jamal

> I also look at the implementation of cls_tcindex and cls_rsvp which still copy
> the old tcf_result, but don't call the tcf_unbind_filter when changing
> the filter.
>
> If it's the intended behaviour, then I'm good with this patch.
>
> Thanks & Regards,
> M A Ramdhan

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[Jamal Hadi Salim]

On Fri, Jul 21, 2023 at 3:00 PM Pedro Tammela <pctammela@mojatatu.com> wrote:
>
> On 21/07/2023 14:48, valis wrote:
> > Three classifiers (cls_fw, cls_u32 and cls_route) always copy
> > tcf_result struct into the new instance of the filter on update.
> >
> > This causes a problem when updating a filter bound to a class,
> > as tcf_unbind_filter() is always called on the old instance in the
> > success path, decreasing filter_cnt of the still referenced class
> > and allowing it to be deleted, leading to a use-after-free.
> >
> > This patch set fixes this issue in all affected classifiers by no longer
> > copying the tcf_result struct from the old filter.
> >
> > valis (3):
> >    net/sched: cls_u32: No longer copy tcf_result on update to avoid
> >      use-after-free
> >    net/sched: cls_fw: No longer copy tcf_result on update to avoid
> >      use-after-free
> >    net/sched: cls_route: No longer copy tcf_result on update to avoid
> >      use-after-free
> >
> >   net/sched/cls_fw.c    | 1 -
> >   net/sched/cls_route.c | 1 -
> >   net/sched/cls_u32.c   | 1 -
> >   3 files changed, 3 deletions(-)
> >
>
> For the series,
>
> Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
> Tested-by: Pedro Tammela <pctammela@mojatatu.com>

For the series:
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>

cheers,
jamal

Re: [PATCH net 1/3] net/sched: cls_u32: No longer copy tcf_result on update to avoid use-after-free

[M A Ramdhan]

On Sat, Jul 22, 2023 at 1:59 AM Pedro Tammela <pctammela@mojatatu.com> wrote:
>
> On 21/07/2023 15:04, M A Ramdhan wrote:
> > On Sat, Jul 22, 2023 at 12:51 AM valis <sec@valis.email> wrote:
> >>
> >> When u32_change() is called on an existing filter, the whole
> >> tcf_result struct is always copied into the new instance of the filter.
> >>
> >> This causes a problem when updating a filter bound to a class,
> >> as tcf_unbind_filter() is always called on the old instance in the
> >> success path, decreasing filter_cnt of the still referenced class
> >> and allowing it to be deleted, leading to a use-after-free.
> >>
> >> Fix this by no longer copying the tcf_result struct from the old filter.
> >>
> >> Fixes: de5df63228fc ("net: sched: cls_u32 changes to knode must appear atomic to readers")
> >> Reported-by: valis <sec@valis.email>
> >> Reported-by: M A Ramdhan <ramdhan@starlabs.sg>
> >> Signed-off-by: valis <sec@valis.email>
> >> Cc: stable@vger.kernel.org
> >> ---
> >>   net/sched/cls_u32.c | 1 -
> >>   1 file changed, 1 deletion(-)
> >>
> >> diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
> >> index 5abf31e432ca..19aa60d1eea7 100644
> >> --- a/net/sched/cls_u32.c
> >> +++ b/net/sched/cls_u32.c
> >> @@ -826,7 +826,6 @@ static struct tc_u_knode *u32_init_knode(struct net *net, struct tcf_proto *tp,
> >>
> >>          new->ifindex = n->ifindex;
> >>          new->fshift = n->fshift;
> >> -       new->res = n->res;
> >>          new->flags = n->flags;
> >>          RCU_INIT_POINTER(new->ht_down, ht);
> >>
> >> --
> >> 2.30.2
> >>
> > Hi,
> >
> > We also thought it's also the correct fixes,
> > but we're not sure because it will always remove the already bound
> > qdisc class when we change the filter, even tho we never specify
> > the new TCA_U32_CLASSID in the new filter.
>
> The user should always explicitly tell the classid. Some other
> classifiers are already behaving like this, these were just wrong.
>

Understand, thanks for the clarification.

Regards,
M A Ramdhan
> >
> > I also look at the implementation of cls_tcindex and cls_rsvp which still copy
> > the old tcf_result, but don't call the tcf_unbind_filter when changing
> > the filter.
>
> Both were deprecated and removed as they were beyond saving.
>
> >
> > If it's the intended behaviour, then I'm good with this patch.
> >
> > Thanks & Regards,
> > M A Ramdhan
>

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[M A Ramdhan]

On Sat, Jul 22, 2023 at 2:56 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> On Fri, Jul 21, 2023 at 3:00 PM Pedro Tammela <pctammela@mojatatu.com> wrote:
> >
> > On 21/07/2023 14:48, valis wrote:
> > > Three classifiers (cls_fw, cls_u32 and cls_route) always copy
> > > tcf_result struct into the new instance of the filter on update.
> > >
> > > This causes a problem when updating a filter bound to a class,
> > > as tcf_unbind_filter() is always called on the old instance in the
> > > success path, decreasing filter_cnt of the still referenced class
> > > and allowing it to be deleted, leading to a use-after-free.
> > >
> > > This patch set fixes this issue in all affected classifiers by no longer
> > > copying the tcf_result struct from the old filter.
> > >
> > > valis (3):
> > >    net/sched: cls_u32: No longer copy tcf_result on update to avoid
> > >      use-after-free
> > >    net/sched: cls_fw: No longer copy tcf_result on update to avoid
> > >      use-after-free
> > >    net/sched: cls_route: No longer copy tcf_result on update to avoid
> > >      use-after-free
> > >
> > >   net/sched/cls_fw.c    | 1 -
> > >   net/sched/cls_route.c | 1 -
> > >   net/sched/cls_u32.c   | 1 -
> > >   3 files changed, 3 deletions(-)
> > >
> >
> > For the series,
> >
> > Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
> > Tested-by: Pedro Tammela <pctammela@mojatatu.com>
>
> For the series:
> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>

For the series:
Reviewed-by: M A Ramdhan <ramdhan@starlabs.sg>
Tested-by: M A Ramdhan <ramdhan@starlabs.sg>

Regards,
M A Ramdhan

>
> cheers,
> jamal

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[Paolo Abeni]

Hi,

On Fri, 2023-07-21 at 17:48 +0000, valis wrote:
> Three classifiers (cls_fw, cls_u32 and cls_route) always copy 
> tcf_result struct into the new instance of the filter on update.
> 
> This causes a problem when updating a filter bound to a class,
> as tcf_unbind_filter() is always called on the old instance in the 
> success path, decreasing filter_cnt of the still referenced class 
> and allowing it to be deleted, leading to a use-after-free.
> 
> This patch set fixes this issue in all affected classifiers by no longer
> copying the tcf_result struct from the old filter.
> 
> valis (3):
>   net/sched: cls_u32: No longer copy tcf_result on update to avoid
>     use-after-free
>   net/sched: cls_fw: No longer copy tcf_result on update to avoid
>     use-after-free
>   net/sched: cls_route: No longer copy tcf_result on update to avoid
>     use-after-free

The SoB in used here sounds really like a pseudonym, which in turn is
not explicitly forbidden by the the process, but a is IMHO a bit
borderline:

https://elixir.bootlin.com/linux/v6.4.5/source/Documentation/process/submitting-patches.rst#L415

@valis: could you please re-submit this using your a more
identificative account? You can retain the already collected acks.

Thanks!

Paolo
> 
>  net/sched/cls_fw.c    | 1 -
>  net/sched/cls_route.c | 1 -
>  net/sched/cls_u32.c   | 1 -
>  3 files changed, 3 deletions(-)
> 

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[valis]

On Tue, Jul 25, 2023 at 2:57 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> Hi,
>
> The SoB in used here sounds really like a pseudonym, which in turn is
> not explicitly forbidden by the the process, but a is IMHO a bit
> borderline:
>
> https://elixir.bootlin.com/linux/v6.4.5/source/Documentation/process/submitting-patches.rst#L415
>
> @valis: could you please re-submit this using your a more
> identificative account? You can retain the already collected acks.

Hi Paolo!

The document you quoted does not forbid pseudonyms.
In fact, it was recently updated to clarify that very fact.

You might want to take a look at this commit:

commit d4563201f33a022fc0353033d9dfeb1606a88330
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Feb 26 11:25:04 2023 -0800

    Documentation: simplify and clarify DCO contribution example language

    Long long ago, in a more innocent time, Greg wrote the clarification for
    how the DCO should work and that you couldn't make anonymous
    contributions, because the sign-off needed to be something we could
    check back with.

    It was 2006, and nobody reacted to the wording, the whole Facebook 'real
    name' controversy was a decade in the future, and nobody even thought
    about it.  And despite the language, we've always accepted nicknames and
    that language was never meant to be any kind of exclusionary wording.

    In fact, even when it became a discussion in other adjacent projects,
    apparently nobody even thought to just clarify the language in the
    kernel docs, and instead we had projects like the CNCF that had long
    discussions about it, and wrote their own clarifications [1] of it.

    Just simplify the wording to the point where it shouldn't be causing
    unnecessary angst and pain, or scare away people who go by preferred
    naming.

    Link: https://github.com/cncf/foundation/blob/659fd32c86dc/dco-guidelines.md
[1]
    Fixes: af45f32d25cc ("We can not allow anonymous contributions to
the kernel")
    Acked-by: Greg KH <gregkh@linuxfoundation.org>
    Acked-by: Michael Dolan <mdolan@linuxfoundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/Documentation/process/submitting-patches.rst
b/Documentation/process/submitting-patches.rst
index 7dc94555417d..fab44ae732e3 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -407,7 +407,7 @@ then you just add a line saying::

        Signed-off-by: Random J Developer <random@developer.example.org>

-using your real name (sorry, no pseudonyms or anonymous contributions.)
+using a known identity (sorry, no anonymous contributions.)


Best regards,

valis

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[Jakub Kicinski]

On Tue, 25 Jul 2023 21:05:23 +0200 valis wrote:
> The document you quoted does not forbid pseudonyms.
> In fact, it was recently updated to clarify that very fact.

We don't know who you are. To my understanding the adjustment means
that you are not obligated to use the name on your birth certificate
but we need to know who you are.

Why is it always "security" people who try act like this is some make
believe metaverse. We're working on a real project with real licenses
and real legal implications.

Your S-o-b is pretty much meaningless. If a "real" person can vouch for
who you are or put their own S-o-b on your code that's fine.

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[valis]

On Tue, Jul 25, 2023 at 10:09 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 25 Jul 2023 21:05:23 +0200 valis wrote:
> > The document you quoted does not forbid pseudonyms.
> > In fact, it was recently updated to clarify that very fact.

Hi Jakub!

>
> We don't know who you are. To my understanding the adjustment means
> that you are not obligated to use the name on your birth certificate
> but we need to know who you are.

I could start a discussion about what makes a name valid, but I'm
pretty sure netdev is not the right place for it.

>
> Why is it always "security" people who try act like this is some make
> believe metaverse. We're working on a real project with real licenses
> and real legal implications.
>
> Your S-o-b is pretty much meaningless. If a "real" person can vouch for
> who you are or put their own S-o-b on your code that's fine.

I posted my patches to this mailing list per maintainer's request and
according to the published rules of the patch submission process as I
understood them.
Sorry if I misinterpreted something and wasted anybody's time.

I'm not going to resubmit the patches under a different name.

Please feel free to use them if someone is willing to sign off on them.

Best regards,

valis

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[Jakub Kicinski]

On Tue, 25 Jul 2023 23:36:14 +0200 valis wrote:
> On Tue, Jul 25, 2023 at 10:09 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > We don't know who you are. To my understanding the adjustment means
> > that you are not obligated to use the name on your birth certificate
> > but we need to know who you are.  
> 
> I could start a discussion about what makes a name valid, but I'm
> pretty sure netdev is not the right place for it.

Agreed, I CCed Greg KH to keep me honest, in case I'm outright
incorrect. If it's a gray zone kinda answer I'm guessing that
nobody here really wants to spend time discussing it.

> > Why is it always "security" people who try act like this is some make
> > believe metaverse. We're working on a real project with real licenses
> > and real legal implications.
> >
> > Your S-o-b is pretty much meaningless. If a "real" person can vouch for
> > who you are or put their own S-o-b on your code that's fine.  
> 
> I posted my patches to this mailing list per maintainer's request and
> according to the published rules of the patch submission process as I
> understood them.
> Sorry if I misinterpreted something and wasted anybody's time.
> 
> I'm not going to resubmit the patches under a different name.
> 
> Please feel free to use them if someone is willing to sign off on them.

If Jamal or anyone else feels like they can vouch for the provenance
of the code, I think that may be the best compromise.

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[Greg Kroah-Hartman]

On Tue, Jul 25, 2023 at 03:03:14PM -0700, Jakub Kicinski wrote:
> On Tue, 25 Jul 2023 23:36:14 +0200 valis wrote:
> > On Tue, Jul 25, 2023 at 10:09 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > > We don't know who you are. To my understanding the adjustment means
> > > that you are not obligated to use the name on your birth certificate
> > > but we need to know who you are.  
> > 
> > I could start a discussion about what makes a name valid, but I'm
> > pretty sure netdev is not the right place for it.
> 
> Agreed, I CCed Greg KH to keep me honest, in case I'm outright
> incorrect. If it's a gray zone kinda answer I'm guessing that
> nobody here really wants to spend time discussing it.

You are not incorrect.

Sorry "valis", we need more information to be able to take patches from
you as an author for obvious reasons.

thanks,

greg k-h

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[Jamal Hadi Salim]

On Tue, Jul 25, 2023 at 6:03 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 25 Jul 2023 23:36:14 +0200 valis wrote:
> > On Tue, Jul 25, 2023 at 10:09 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > > We don't know who you are. To my understanding the adjustment means
> > > that you are not obligated to use the name on your birth certificate
> > > but we need to know who you are.
> >
> > I could start a discussion about what makes a name valid, but I'm
> > pretty sure netdev is not the right place for it.
>
> Agreed, I CCed Greg KH to keep me honest, in case I'm outright
> incorrect. If it's a gray zone kinda answer I'm guessing that
> nobody here really wants to spend time discussing it.
>
> > > Why is it always "security" people who try act like this is some make
> > > believe metaverse. We're working on a real project with real licenses
> > > and real legal implications.
> > >
> > > Your S-o-b is pretty much meaningless. If a "real" person can vouch for
> > > who you are or put their own S-o-b on your code that's fine.
> >
> > I posted my patches to this mailing list per maintainer's request and
> > according to the published rules of the patch submission process as I
> > understood them.
> > Sorry if I misinterpreted something and wasted anybody's time.
> >
> > I'm not going to resubmit the patches under a different name.
> >
> > Please feel free to use them if someone is willing to sign off on them.
>
> If Jamal or anyone else feels like they can vouch for the provenance
> of the code, I think that may be the best compromise.

I am more than happy to add my SoB - these are real issues being fixed
and this is not the first time that Valis identified and helped
resolve legit issues in tc.

cheers,
jamal

Re: [PATCH net 0/3] net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route

[Jakub Kicinski]

On Wed, 26 Jul 2023 09:59:02 -0400 Jamal Hadi Salim wrote:
> > If Jamal or anyone else feels like they can vouch for the provenance
> > of the code, I think that may be the best compromise.  
> 
> I am more than happy to add my SoB - these are real issues being fixed
> and this is not the first time that Valis identified and helped
> resolve legit issues in tc.

Great! Please repost with your signoffs.