netdev - Re: [RFC] Control Group Classifier

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 9 Sep 2008 02:06:27 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	Ranjit Manomohan <ranjitm@...gle.com>
Cc:	netdev@...r.kernel.org, Paul Menage <menage@...gle.com>
Subject: Re: [RFC] Control Group Classifier

* Ranjit Manomohan <ranjitm@...gle.com> 2008-09-08 14:28
> Wouldn't this cause a lot of packets (like acks)  to be incorrectly
> classifed to the current tasks cgroup although it may not have
> anything to do with them? That is the reason I chose to put the
> classid into the socket at creation time.

In its current form, it does not work if the packet is rescheduled
or not sent in the context of a process. Such packets simply end
up not being classified at all. In the most common case, the packet
is not queued before it hits the qdisc so this takes away a lot of
complexity and is very fast but should still be sufficient.

Alternatively I also thought about doing a socket lookup in the
classifier (if !skb->sk) and store the classid in the socket. This
would add more flexibility and work for ingress traffic whitout
adding pollution to the sk_buff. It adds a heavy operation to the
classification process though as it would probably require a lock.
--
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