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:	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ