Messages in this thread |  | | | Date | Tue, 11 Nov 2008 16:32:21 +0900 | | From | Kentaro Takeda <> | | Subject | Re: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management functions. |
| |
Andrew Morton wrote: >> 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? It is called whenever open() / mkdir() / unlink() etc. are called, but not when read() / write() are called. Frequency of open() / mkdir() / unlink() etc. are much lower than frequency of read() / write(). Main cost of pathname based access control is strcmp()ing (or even regexp()ing) over the list of strings, therefore zeroing buffer for pathname is relatively negligible.
>>>> 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! Well, regarding memory usage, it is easy to follow "one-value-per-file rule". But regarding policy information (which is managed as lists), "one-value-per-file rule" is not suitable. I think none of SELinux, SMACK, AppArmor, TOMOYO create "one pseudo file for one value". This /sys/kernel/security/tomoyo/ interface is used by only TOMOYO's management programs, and not by generic programs.
Regards,
|  |