linux-kernel - Re: [RFC] How to handle the rules engine for cgroups

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: <48768D53.4000803@redhat.com>
Date:	Thu, 10 Jul 2008 15:29:39 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Rik van Riel <riel@...hat.com>, Paul Menage <menage@...gle.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Libcg Devel Mailing List <libcg-devel@...ts.sourceforge.net>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Peter Zijlstra <pzijlstr@...hat.com>,
	Kazunaga Ikeno <k-ikeno@...jp.nec.com>,
	Morton Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Graf <tgraf@...hat.com>
Subject: Re: [RFC] How to handle the rules engine for cgroups

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vivek Goyal wrote:
> Before exec, we should be able to determine the
> migration policy related to process/thread (either by reading file or
> something else etc). Set the policy through cgroup file system. If exec
> fails for some reason, we just need to go back to cgroup file system to
> undo the effect of setting migration policy previously set for that thread.

That's what I said.  It would be necessary to get the old state and
reset it if necessary.

As for the interface: I hope nobody honestly thinks that it is doable to
perform a whole bunch of filesystem operations for every exec.

And more: reading a rule file, interpreting the rules to find the best
match, etc is also too expensive.  Every process would have to read the
rule file again.  If this is non-trivial or the rule file is large, the
cost of an exec could easily be overshadowed by the cost of this
preparation.  Unlike the kernel, the userlevel runtime cannot in general
amortize the cost over several exec calls.  Handling all this in the
kernel wouldn't have any of these problems.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkh2jVMACgkQ2ijCOnn/RHQ6JACgx4W0dUh/MK6po23D1ObcnsKA
HOAAn2Qfrh8m5zsdHQoniaoLl12Ut3ZE
=IU/X
-----END PGP SIGNATURE-----
--
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/