linux-kernel - Re: [PATCH 1/2] CAPABILITIES: add cap

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] [day] [month] [year] [list]

Message-ID: <20150313161330.GC2527@mguzik>
Date:	Fri, 13 Mar 2015 17:13:31 +0100
From:	Mateusz Guzik <mguzik@...hat.com>
To:	Paul Moore <pmoore@...hat.com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Eric Paris <eparis@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 1/2] CAPABILITIES: add cap_isequal helper

On Fri, Mar 13, 2015 at 10:02:46AM -0400, Paul Moore wrote:
> On Monday, March 09, 2015 09:35:46 PM Mateusz Guzik wrote:
> > Can be used to determine whether two given sets have the same
> > capabilities.
> > 
> > Signed-off-by: Mateusz Guzik <mguzik@...hat.com>
> > ---
> >  include/linux/capability.h | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/include/linux/capability.h b/include/linux/capability.h
> > index af9f0b9..2fcf941 100644
> > --- a/include/linux/capability.h
> > +++ b/include/linux/capability.h
> > @@ -155,6 +155,16 @@ static inline int cap_isclear(const kernel_cap_t a)
> >  	return 1;
> >  }
> > 
> > +static inline int cap_isequal(const kernel_cap_t a, const kernel_cap_t b)
> > +{
> > +	unsigned __capi;
> > +	CAP_FOR_EACH_U32(__capi) {
> > +		if (a.cap[__capi] != b.cap[__capi])
> > +			return 0;
> > +	}
> > +	return 1;
> > +}
> 
> I realize it is currently only a two pass loop so probably not that big of a 
> deal, but couldn't you accomplish the same with a memcmp()?  I suppose the 
> above implementation might be faster than those architectures which use the 
> generic memcmp() implementation, but I wonder if the arch-specific memcmp() 
> implementations would be faster.
> 

Well I did it this way for consistency with the rest of the file. Trying
to use memcpy with only 2 elements to compare may be a dubious
optimisation and would require providing additional macros for cap size.

As such, I would prefer to keep the loop as it is. This can be changed
should caps ever grow.

> Also, what is the main motivation for this patchset?  Do you have a workload 
> that is being hit hard by prepare_creds()?
> 

It's just something I stumbled upon and decided to microoptimize (fwiw,
faccessat is called quite often, but not enough for this change to be
world-changing).

Given the triviality of the patch I figured it should be fine to do it.

-- 
Mateusz Guzik
--
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/