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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 10 Sep 2008 10:58:08 -0700
From:	"Ranjit Manomohan" <ranjitm@...gle.com>
To:	"Thomas Graf" <tgraf@...g.ch>
Cc:	netdev@...r.kernel.org, "Paul Menage" <menage@...gle.com>
Subject: Re: [RFC] Control Group Classifier

On Mon, Sep 8, 2008 at 5:06 PM, Thomas Graf <tgraf@...g.ch> wrote:
> * 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.
>

Not clear to me why would it need a lock (for transmit)?  The skbuff
holds a reference to the socket so it should be safe to access without
any additional overhead. I have resent my patchset which does exactly
this. Besides like you mentioned you need it anyway for inbound packet
classification.

Our current internal implementation for inbound handling is:

Use the ingress qdisc to match all packets and perform an additional
action of looking up their socket for the cgroup classid and redirect
all packets to the ifb device. The same cgroups classifier can then be
used there to limit inbound traffic.

The only added complication here is that the new action will have to
do a socket lookup which requires simple helpers from the registered
protocols like TCP.

I shall send out the patches for this shortly.

-Thanks,
Ranjit
--
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