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: <200905041524.GGH52160.FFFVMSJOOLtHOQ@I-love.SAKURA.ne.jp>
Date:	Mon, 4 May 2009 15:24:02 +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

Pavel Machek wrote:
> The document above says otherwise. 'There is no way except rebooting
> the system that can free unneeded memory' certainly looks like memory
> leak. Plus it sounds like if you change the policy, it will not free
> the old one, either.

Comments on documentation are also appreciated.
Let me explain it with below examle.

# echo 'allow_read /lib/libc-2.5.so' | ccs-loadpolicy -e
# echo 'delete allow_read /lib/libc-2.5.so' | ccs-loadpolicy -e
# echo 'allow_read /lib/libc-2.5.so' | ccs-loadpolicy -e
# echo 'allow_read /lib/libc-2.6.so' | ccs-loadpolicy -e

In the first line, new memory is allocated because that element has never been
added to the list before.
In the second line, memory used for the deleted element is not released.
In the third line, new memory is not allocated because that element has been
added in the past.
In the fourth line, new memory is allocated because that element has never been
added to the list before.

Memory which becomes garbage (which some people call as "memory leak") is
quite little because a sane administrator won't add random elements and delete
them.

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. But if we can find
a way to detect no longer referenced elements, we would be able to add some
garbage collector. (Before we start implementing garbage collector, I'd like to
hear end-user's opinion whether TOMOYO wants garbage collector or not.)

Thanks.
--
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