Date:   Thu, 03 Aug 2023 22:20:17 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Christian Göttsche <cgzones@...glemail.com>,
        selinux@...r.kernel.org
Cc:     Stephen Smalley <stephen.smalley.work@...il.com>,
        Eric Paris <eparis@...isplace.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/9] selinux: use u32 as bit type in ebitmap code

On Jul 28, 2023 =?UTF-8?q?Christian=20G=C3=B6ttsche?= <cgzones@...glemail.com> wrote:
> 
> The extensible bitmap supports bit positions up to U32_MAX due to the
> type of the member highbit being u32.  Use u32 consistently as the type
> for bit positions to announce to callers what range of values is
> supported.
> 
> Signed-off-by: Christian Göttsche <cgzones@...glemail.com>
> ---
> v2: avoid declarations in init-clauses of for loops
> ---
>  security/selinux/ss/ebitmap.c | 32 ++++++++++++++++----------------
>  security/selinux/ss/ebitmap.h | 32 ++++++++++++++++----------------
>  2 files changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/security/selinux/ss/ebitmap.c b/security/selinux/ss/ebitmap.c
> index 77875ad355f7..6ab2baf4cfb5 100644
> --- a/security/selinux/ss/ebitmap.c
> +++ b/security/selinux/ss/ebitmap.c
> @@ -24,7 +24,7 @@
>  #include "ebitmap.h"
>  #include "policydb.h"
>  
> -#define BITS_PER_U64	(sizeof(u64) * 8)
> +#define BITS_PER_U64	((u32)(sizeof(u64) * 8))
>  
>  static struct kmem_cache *ebitmap_node_cachep __ro_after_init;
>  
> @@ -82,7 +82,8 @@ int ebitmap_cpy(struct ebitmap *dst, const struct ebitmap *src)
>  int ebitmap_and(struct ebitmap *dst, const struct ebitmap *e1, const struct ebitmap *e2)
>  {
>  	struct ebitmap_node *n;
> -	int bit, rc;
> +	u32 bit;
> +	int rc;
>  
>  	ebitmap_init(dst);
>  
> @@ -113,8 +114,7 @@ int ebitmap_netlbl_export(struct ebitmap *ebmap,
>  {
>  	struct ebitmap_node *e_iter = ebmap->node;
>  	unsigned long e_map;
> -	u32 offset;
> -	unsigned int iter;
> +	u32 offset, iter;
>  	int rc;

In this function 'iter' is used to iterate through ebitmap_node::maps
and it thus only indirectly related to an ebitmap spot/offset.

I don't think this change harms anything, but it isn't strictly
necessary.

>  	if (e_iter == NULL) {
> @@ -259,7 +259,7 @@ int ebitmap_contains(const struct ebitmap *e1, const struct ebitmap *e2, u32 las
>  	return 1;
>  }
>  
> -int ebitmap_get_bit(const struct ebitmap *e, unsigned long bit)
> +int ebitmap_get_bit(const struct ebitmap *e, u32 bit)
>  {
>  	const struct ebitmap_node *n;
>  
> @@ -276,7 +276,7 @@ int ebitmap_get_bit(const struct ebitmap *e, unsigned long bit)
>  	return 0;
>  }
>  
> -int ebitmap_set_bit(struct ebitmap *e, unsigned long bit, int value)
> +int ebitmap_set_bit(struct ebitmap *e, u32 bit, int value)
>  {
>  	struct ebitmap_node *n, *prev, *new;
>  
> @@ -287,7 +287,7 @@ int ebitmap_set_bit(struct ebitmap *e, unsigned long bit, int value)
>  			if (value) {
>  				ebitmap_node_set_bit(n, bit);
>  			} else {
> -				unsigned int s;
> +				u32 s;
>  
>  				ebitmap_node_clr_bit(n, bit);
>  
> @@ -365,12 +365,12 @@ void ebitmap_destroy(struct ebitmap *e)
>  int ebitmap_read(struct ebitmap *e, void *fp)
>  {
>  	struct ebitmap_node *n = NULL;
> -	u32 mapunit, count, startbit, index;
> +	u32 mapunit, count, startbit, index, i;
>  	__le32 ebitmap_start;
>  	u64 map;
>  	__le64 mapbits;
>  	__le32 buf[3];
> -	int rc, i;
> +	int rc;
>  
>  	ebitmap_init(e);
>  
> @@ -384,7 +384,7 @@ int ebitmap_read(struct ebitmap *e, void *fp)
>  
>  	if (mapunit != BITS_PER_U64) {
>  		pr_err("SELinux: ebitmap: map size %u does not "
> -		       "match my size %zd (high bit was %d)\n",
> +		       "match my size %d (high bit was %d)\n",
>  		       mapunit, BITS_PER_U64, e->highbit);
>  		goto bad;
>  	}
> @@ -471,18 +471,18 @@ int ebitmap_read(struct ebitmap *e, void *fp)
>  int ebitmap_write(const struct ebitmap *e, void *fp)
>  {
>  	struct ebitmap_node *n;
> -	u32 count;
> +	u32 bit, count, last_bit, last_startbit;
>  	__le32 buf[3];
>  	u64 map;
> -	int bit, last_bit, last_startbit, rc;
> +	int rc;
>  
>  	buf[0] = cpu_to_le32(BITS_PER_U64);
>  
>  	count = 0;
>  	last_bit = 0;
> -	last_startbit = -1;
> +	last_startbit = (u32)-1;

I can't say I'm as current on all of the C standards and compilier
oddities as some other in the Linux kernel space, but my
understanding is that on assignment the right value is always
implicitly type cast to the type of the left variable, is that not
true?  Assuming it is true, I think this explicit cast isn't
necessary and could actually be harmful if we need to change the
ebitmap types in the future.

>  	ebitmap_for_each_positive_bit(e, n, bit) {
> -		if (rounddown(bit, (int)BITS_PER_U64) > last_startbit) {
> +		if (last_startbit == (u32)-1 || rounddown(bit, BITS_PER_U64) > last_startbit) {

This is a little more challenging as I know the rules for integer
comparisons are not quite as simple as assignments, but I do question
if the above change is an improvement.

One possibility would be to explicitly match the types, for example:

 x == (typeof(x))-1 

>  			count++;
>  			last_startbit = rounddown(bit, BITS_PER_U64);
>  		}
> @@ -496,9 +496,9 @@ int ebitmap_write(const struct ebitmap *e, void *fp)
>  		return rc;
>  
>  	map = 0;
> -	last_startbit = INT_MIN;
> +	last_startbit = (u32)-1;
>  	ebitmap_for_each_positive_bit(e, n, bit) {
> -		if (rounddown(bit, (int)BITS_PER_U64) > last_startbit) {
> +		if (last_startbit == (u32)-1 || rounddown(bit, BITS_PER_U64) > last_startbit) {
>  			__le64 buf64[1];

Both of these changes are discussed above.

>  			/* this is the very first bit */

--
paul-moore.com

Powered by blists - more mailing lists