linux-kernel - Re: [TOMOYO 1/2] tomoyo: add Documentation/tomoyo.txt

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, 6 May 2009 21:16:51 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	pavel@....cz
Cc:	jmorris@...ei.org, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [TOMOYO 1/2] tomoyo: add Documentation/tomoyo.txt

Tetsuo Handa wrote:
> TOMOYO has cursors used for resuming list traversal from arbitrary elements.
> I tried to add refcounter to each element, but the code became too ugly to
> maintain. Thus, I simplified list traversal by guaranteeing all elements
> pointed by cursors are permanent. As of now, we can't release memory used by
> the deleted element because we don't manage the list of cursors to make sure
> that there is no cursor which refers the deleted element.

Just for information, I tried to implement some garbage collector.
http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.2.x/tomoyo-lsm/patches/tomoyo-gc.patch?view=
markup&revision=2506&root=tomoyo
Not checked the patch for details, but I think it is less ugly than
my previous implementation.

Rough estimate is shown below.

(1) Current implementation, booted CentOS 5.3 with learning mode.

Memory: 492736k/524288k available (4730k kernel code, 30668k reserved, 4947k data, 1668k init, 0k 
highmem)

# ccs-savepolicy -u
Shared:      135168
Private:     208896
Dynamic:        704
Total:       344768

(2a) With the patch above, booted CentOS 5.3 with learning mode.

Memory: 492736k/524288k available (4732k kernel code, 30676k reserved, 4953k data, 1668k init, 0k 
highmem)

# ccs-savepolicy -u
Shared:      333280
Private:     200000
Dynamic:        704
Total:       533984

(2b) With the patch above, removed policy as much as possible after (2a).

# ccs-savepolicy -u
Shared:        2400
Private:       1120
Dynamic:        704
Total:         4224

The difference comes from mainly how TOMOYO keeps string data.

Case 1 embeds multiple strings into kmalloc(PAGE_SIZE), but can't kfree().
By not implementing garbage collector, we can save about 200kB of RAM
if an administrator does not delete current policy.

Case 2a and 2b use kstrdup() for each string, and can kfree().
By implementing garbage collector, we can release about 520kB of RAM
if an administrator completely deletes current policy.

Please remember that in case 1, reloading the policy which was loaded in the
past will not consume memory (because it simply clears is_deleted flag instead
of allocating memory).
The amount of memory finally saved depends on how large policy changes occur.
--
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/