netdev - Re: [PATCH net-next 1/1] net_sched: Introduce skbmod 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]

Date:	Wed, 20 Jul 2016 02:23:03 +0200
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Cong Wang <xiyou.wangcong@...il.com>
CC:	Jamal Hadi Salim <jhs@...atatu.com>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: Re: [PATCH net-next 1/1] net_sched: Introduce skbmod action

On 07/19/2016 08:04 PM, Cong Wang wrote:
> On Tue, Jul 19, 2016 at 8:03 AM, Daniel Borkmann <daniel@...earbox.net> wrote:
>> On 07/19/2016 03:56 PM, Jamal Hadi Salim wrote:
>> [...]
>>>>
>>>> But apart from this,
>>>> neither pedit nor tcf_skbmod_run() here handle checksum complete, so
>>>> you'll
>>>> potentially get false positives wrt csum corruption and drops as a result
>>>> when using either of the two.
>>>
>>> pedit maybe tricky. Any suggestions?
>>> On tcf_skbmod_run, mostly ignorance: while doing only ethernet updates;
>>> is it still needed to do the checksum complete?
>>
>> Well, what Cong recently fixed with mirred was related to mac header ...
>>
>> You probably need skb_postpull_rcsum(), skb_postpush_rcsum() pair.
>>
>> Also, what about skb_try_make_writable()?
>
> I don't think so. 1) checksum is supposed to be done by csum action
> rather than pedit (or skbmod if it matters), 2) csum action currently
> already handles that correctly for both egress and ingress: 2a)
> CHECKSUM_COMPLETE is meaningless on egress; 2b) it forces
> CHECKSUM_COMPLETE to be CHECKSUM_NONE on ingress
> and it is correctly respected.

Ahh, right, so it redoes entire csums when worst-case changing one byte
only, since it cannot know what other actions like pedit did previously.
But it also means for your l2 mac addr changes to force a CHECKSUM_COMPLETE
into CHECKSUM_NONE with csum action that you need to call into one of the
l3/l4 helpers as far as I see.