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: <04768243-06E2-469E-AC83-95892089FE7B@darbyshire-bryant.me.uk>
Date:   Sat, 23 Mar 2019 17:45:19 +0000
From:   Kevin 'ldir' Darbyshire-Bryant <ldir@...byshire-bryant.me.uk>
To:     Cong Wang <xiyou.wangcong@...il.com>
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

Hi Cong,

Thanks for your responses so far.

> On 22 Mar 2019, at 23:09, Cong Wang <xiyou.wangcong@...il.com> wrote:
> 
> 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 will remove the functionality from conndscp that changes the conntrack mark, so that it only restores the mark into the diffserv field.

So that I’m clear about which direction I should be headed:

Bearing in mind that conndscp writes to the skb’s iphdr diffserv field and *not* skb->fwmark, do you still desire to see the dscp restoration code done as part of connmark.  In other words NOT have a separate conndscp module?

> 
> 
>>> 
>>> 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.

I have a working copy/paste abomination example that creates an XT_CONNMARK_SAVEDSCP type function and will consult the netfilter devs for feedback.


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A