linux-kernel - Re: [PATCH v2 1/2] cgroups: allow a cgroup subsystem to reject a fork

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-next>] [day] [month] [year] [list]

Message-ID: <CAOviyaj3mf66ho15WrD8qB=ECxKWYTAkWodxWaFVMWeZG4d0FQ@mail.gmail.com>
Date:	Tue, 10 Mar 2015 19:19:06 +1100
From:	Aleksa Sarai <cyphar@...har.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	lizefan@...wei.com, mingo@...hat.com, peterz@...radead.org,
	richard@....at,
	Frédéric Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	Aleksa Sarai <cyphar@...har.com>
Subject: Re: [PATCH v2 1/2] cgroups: allow a cgroup subsystem to reject a fork

Hi Tejun,

>> The reason is that when cgroup_can_fork() is called, the css_set doesn't
>> contain the pids cgroup it's forking to. You can verify this by moving that
>> segment of code back to it's original position and compiling/rebooting/testing
>> the pids cgroup. You will get a WARN each time you try to attach to a new pids
>> cgroup, because when your shell forks the counter for the original pids cgroup
>> hierarchy gets incremented but when the command exits the counter for the *new*
>> pids cgroup hierarchy gets decremented. Essentially it's because we need to
>> reference the css_set of the newly forked process (as it exists when
>> cgroup_fork() runs) when incrementing the hierarchy -- otherwise we will
>> increment/decrement a different hierarchy between fork() and exit().
>>
>> If there's a correct way of doing this, I'm all ears. I had a bad feeling that
>> moving that section would break the whole visibility issue in the same fashion
>> as I did in v1 of this patchset. The thing is, I'm not sure there's a way to
>> access the new css_set of the task as though it is attached without making it
>> visible prematurely (because we need the css_set to refer to the right
>> hierarchy in order to conditionally decide the fork).
>
> You can charge the parent's at can_attach(), remember which one you
> charged, and at post_fork() if the parent's has changed inbetween, fix
> it up.  Again, you may end up breaking the hard limit of the new pids
> cgroup at this point but that's fine.  The cgroup membership changing
> inbetween pretty much implies that organization operation happened
> inbetween.

I'm not sure how to check for equality between two `css_set`s (or just two
`css`s). Is there a function to do so? Also, I'm not sure if there's a nice way
of doing a charge that stops if you hit a certain `css` (unless we start
passing `css_set`s to the fork/exit callbacks -- and then we can uncharge the
old css_set and charge the new one).

--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/