Re: [PATCH 3/7] NetLabel: CIPSOv4 engine

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

On Sunday 16 July 2006 9:12 pm, David Miller wrote:
> From: Paul Moore <paul.moore@hp.com>
> Date: Sun, 16 Jul 2006 12:10:44 -0400
>
> > On Friday 14 July 2006 10:03 pm, James Morris wrote:
> > > On Fri, 14 Jul 2006, paul.moore@hp.com wrote:
> > > > +/**
> > > > + * cipso_v4_bitmap_walk - Walk a bitmap looking for a bit
> > > >
> > > > + * cipso_v4_bitmap_setbit - Sets a single bit in a bitmap
> > >
> > > Can you use lib/bitmap.c instead?
> >
> > Looking again at include/asm/bitops.h I think I now remember why I
> > decided not to use them in the first place.
>
> lib/bitmap.c and the asm/bitops.h operations are two entirely
> different animals.

I probably should have been more clear - I didn't see anything in lib/bitmap.c 
(or include/linux/bitmap.h) that I think would have been useful.  However, 
include/linux/bitmap.h makes reference to asm/bitops.h which does have some 
function which may have been useful if they didn't have the length 
restrictions.

> Wrt. your asm/bitops.h concerns, is there any reason you cannot pad
> out your bitmaps to be a modulo of "long" which is required for
> those routines?

Right now I use both the bitmap_walk() and bitmap_setbit() routines to deal 
with both CIPSO tags straight from the sk_buff as well as the internal bitmap 
representation.  Padding out the internal bitmaps would require some code 
changes but there isn't much I can do about the packet I don't believe.  True 
it would probably be okay for most packets to assume you could access an 
entire "long"s worth of memory but then again it would only take one evil 
packet to start causing problems ...

-- 
paul moore
linux security @ hp