netdev - Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set

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: <20080428072128.GB5379@gerrit.erg.abdn.ac.uk>
Date:	Mon, 28 Apr 2008 08:21:28 +0100
From:	Gerrit Renker <gerrit@....abdn.ac.uk>
To:	David Miller <davem@...emloft.net>
Cc:	tomasz@...belny.oswiecenia.net, dccp@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked
	version of Tomasz's patch set

| >  * skb->priority now cleared before passing the skb onto layer 3;
<snip>
| 
| If this usage of skb->priority is going to override the
| IP_TOS socket option setting, I don't think it's a good
| idea.
| 
| Right now every packet output goes through ip_output.c
| which sets skb->priority to sk->sk_priority, which is set
| by the user via the IP_TOS socket option in ip_sockglue.c

That is actually the key point I wanted to ask about. 

The patch exploits that the assignment happens later, on layer3,
with these conditions:

 * Output path only (sent by the DCCP output module on this host).

 * It is not clear which value skb->priority has until reaching the
   output functions in ipv4/ip_output.c and ipv6/ip6_output.c. There
   is no memset on this field in net/core/skbuff.c and the skb comes
   from a cache, so presumably skb->priority is undefined until it
   is assigned from sk->sk_priority.

 * The assignment for appletalk (net/appletalk/aarp.c), econet,
   IPv4/6 raw sockets, packet sockets (af_packet.c) is similar, so
   the assumption was that the 4 bytes of skb->priority are not
   used while the skb is on layer 4.

 * The only place where I can see mischief happen is when there is
   a fork where the skb is not passed on to layer 3, using either
   __copy_skb_header (copies the priority field) or skb_segment.

Since I can currently not see the last point happen within DCCP, I think
that the use of skb->priority for layer 4 (DCCP) is safe.

So the remaining question was whether maintainers would be okay with
this "overloading" of the field (Arnaldo seems ok with it). 

Part of the patch tried to make this use obvious, by aligning the 
"prio" policy with the semantics of SO_PRIORITY.

Gerrit

The University of Aberdeen is a charity registered in Scotland, No SC013683.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html