[lkml]   [2008]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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

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


     \ /
      Last update: 2008-11-11 08:35    [W:0.024 / U:7.424 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site