Re: [RFC PATCH] SELinux: Cleanup the secid/secctx conversion functions

[Paul Moore <paul.moore@hp.com>]

On Friday 29 February 2008 1:41:54 pm Todd Miller wrote:
> Paul Moore wrote:
> > The strlcpy() implementation does a strlen() and a memcpy() call
> > along with two comparisons and some trivial math.  The strcat()
> > implementation does pretty much the same thing but with less
> > comparisons and no additional math.  The strcpy() implementation
> > only does a byte-by-byte copy which should be faster then strlcpy()
> > even when one factors in an optimized memcpy() implementation due
> > to the strlen() call.
>
> The difference is that with strcat() you are also finding the length
> of dest whereas which strlcpy() you only need to find the length of
> src.

True, strcat() does do a strlen() on dest while strlcpy() does a 
strlen() on src and in this case dest is almost always going to be 
bigger then src.

> I really doubt it makes a measurable difference and things may 
> be muddied by gcc inlining some of the standard str* functions.

Agree.

Also, (this starts getting into architecture specifics) on x86 (not 
x86_64) I'm pretty sure all function arguments are passed on the stack 
and strlcpy() requires three arguments versus strcat()/strcpy() which 
require only two.  However, at this point I think the argument is 
starting to get a bit ridiculous.

> However, you definately do not need the final strlen(ctx) in either
> case since you know that *scontext_len - 1 == strlen(ctx).

Disagree.  At the point in time of the final strlen(ctx) call ctx looks 
like this (note the lack of MLS range):

    user_u:role_r:type_t

... where as scontext_len is equal to the strlen() of the full context 
(MLS included).  The results of strlen(*scontext) and *scontext_len are 
not the same until after the call to mls_sid_to_context().

> I'm not sanctioning James' abuse of strlcpy(); I think it is
> pointless to try and guess which is faster without actually
> benchmarking it.

Yep ... slow news day and this discussion seems a lot safer then the 
current labeled NFS discussion ;)

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.