netdev - Re: [RFC PATCH 1/1 v2] net: sched: Introduce conndscp action

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM_iQpUcy6D_bFdV3tyMuvpMDqRJxhKdGBWZVesALkfSgtOjPQ@mail.gmail.com>
Date:   Fri, 22 Mar 2019 16:09:24 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     "Kevin 'ldir' Darbyshire-Bryant" <ldir@...byshire-bryant.me.uk>
Cc:     "jhs@...atatu.com" <jhs@...atatu.com>,
        "jiri@...nulli.us" <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 1/1 v2] net: sched: Introduce conndscp action

On Fri, Mar 22, 2019 at 3:06 PM Kevin 'ldir' Darbyshire-Bryant
<ldir@...byshire-bryant.me.uk> wrote:
>
>
>
> > On 22 Mar 2019, at 21:31, Cong Wang <xiyou.wangcong@...il.com> wrote:
> >
> > On Fri, Mar 22, 2019 at 1:50 PM Kevin 'ldir' Darbyshire-Bryant
> > <ldir@...byshire-bryant.me.uk> wrote:
> >>
> >>
> >>
> >>> On 22 Mar 2019, at 20:05, Cong Wang <xiyou.wangcong@...il.com> wrote:
> >>>
> >>> On Fri, Mar 22, 2019 at 11:26 AM Kevin 'ldir' Darbyshire-Bryant
> >>> <ldir@...byshire-bryant.me.uk> wrote:
> >>>>
> >>>> Hi Cong,
> >>>>
> >>>> Thanks for your questions.
> >>>>
> >>>>> On 22 Mar 2019, at 17:39, Cong Wang <xiyou.wangcong@...il.com> wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> On Fri, Mar 22, 2019 at 7:09 AM Kevin 'ldir' Darbyshire-Bryant
> >>>>> <ldir@...byshire-bryant.me.uk> wrote:
> >>>>>>
> >>>>>> Conndscp is a new tc filter action module.  It is designed to copy DSCPs
> >>>>>> to conntrack marks and the reverse operation of conntrack mark contained
> >>>>>> DSCPs to the diffserv field of suitable skbs.
> >>>>>>
> >>>>>
> >>>>> Is it possible and feasible to integrate this into connmark?
> >>>>
> >>>> I started off coding it that way but quickly ran into my limitations with netlink messaging and became frustrated.  Aside from my own limitations, conndscp ab/uses tcf_qstats requeues & overlimits to indicate DSCP->MARK->DSCP operations and has been useful in proving DSCP/marking operations are occurring in the right times/places.  Integrating with connmark which itself uses overlimits to indicate conntrack mark to skb->mark restoration would lose that differentiation/confirmation/debug ability.  A possibility is to ab/use the drop count instead but I fear that would cause confusion.
> >>>
> >>> This sounds problematic, why a flag/parameter doesn't work?
> >>>
> >> I don’t understand the question?
> >
> > You said conndscp uses some stat to save some configuration
> > information, that is, DSCP->MARK->DSCP operations. But
> > configuration information is usually saved in a parameter struct
> > or some priviate flag. So, I have to ask why a flag/parameter doesn't
> > work for this case?
> >
> > And, you also implied this is a barrier for you to reuse connmark
> > action.
> >
> > Am I misunderstanding anything here?
>
> Ahh!  I understand the question, apologies if I was not clear.  conndscp like connmark reports some status information back to tc via tcf_qstats structure.  connmark uses ‘overlimits’ to report the number of marks restored from conntrack->mark to skb->mark.  conndscp uses ‘overlimits’ and ‘requeues’ to report status about how many marks it has restored/set. e.g.

I see, I didn't know this, but it is not hard to add a connmark
specific stat for this, I don't know why it has to reuse 'overlimit',
perhaps just to save some memory space.

Unless you have legitimate reasons, you don't have to reuse
it. It is just confusing.


> >
> > I guess you should look into netfilter to modify any conntrack attribute,
> > it is at least where conntrack belongs to. :)
>
> So I wonder if an XT_CONNMARK_SAVEDSCP option in xt_connmark would be more acceptable?

I think so, but I have to say I am not a netfilter expert. You probably
want to check it with netfilter developers too.

Thanks.