linux-kernel - Re: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management functions.

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:	Mon, 10 Nov 2008 22:46:09 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Kentaro Takeda <takedakn@...data.co.jp>
Cc:	haradats@...data.co.jp, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, penguin-kernel@...ove.SAKURA.ne.jp
Subject: Re: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname
 management functions.

On Tue, 11 Nov 2008 15:34:39 +0900 Kentaro Takeda <takedakn@...data.co.jp> wrote:

> Andrew Morton wrote:
> >>> Note that I said "kmalloc", not "kzalloc".  This function zeroes
> >>> everything all the time, and surely that is not necessary.  It's just a
> >>> waste of CPU time.
> >>>
> >> Callers of tmy_alloc assume that allocated memory is zeroed.
> > 
> > That isn't the point.  For programmer convenience we could make
> > __alloc_pages() and kmalloc() zero all the memory too.  But we don't
> > because it is slow.
> Are you saying "make the callers of tmy_alloc() tolerable with
> uninitialized memory"?

Well.  That would be a desirable objective.  I can understand the
reasons for taking the easy way out.  Given that Tomoyo doesn't seem to
ever free memory again, one hopes that this function doesn't get called
a lot, so the performance impact of zeroing out all that memory should
be negligible.

I think.  Maybe I misinterpreted tmy_alloc(), and perhaps it _is_
called frequently?

> >> Creating pseudo files for each variables is fine, though I don't see
> >> advantage by changing from
> >> "echo Shared: 16777216 > /sys/kernel/security/tomoyo/meminfo" to
> >> "echo 16777216 > /sys/kernel/security/tomoyo/quota/shared_memory".
> > 
> > Well for starters, the existing interface is ugly as sin and will make
> > kernel developers unhappy.
> > 
> > There is a pretty strict one-value-per-file rule in sysfs files, and
> > "multiple tagged values in one file" violates that a lot.
> /sys/kernel/security/ is not sysfs but securityfs.
> Does "one-value-per-file rule" also apply to securityfs?

It should apply.  It's not so much a matter of rules and regulations. 
One needs to look at the underlying _reasons_ why those rules came
about.  We got ourselves into a sticky mess with procfs with all sorts
of ad-hoc data presentation and input formatting.  It's inconsistent,
complex, makes tool writing harder, etc.

So we recognised our mistakes and when sysfs (otherwise known as procfs
V2 :)) came about we decided that sysfs files should not make the same
mistakes.

So, logically, that thinking should apply to all new pseudo-fs files. 
Even, in fact, ones which are in /proc!
--
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/