On Wednesday, August 22 2007 5:20:05 pm Thomas Graf wrote:
> * Paul Moore <[EMAIL PROTECTED]> 2007-08-22 16:31
>
> > We're currently talking about several different ideas to solve the
> > problem, including leveraging the sk_buff.secmark field, and one of the
> > ideas was to add an additional field to the sk_buff structure.  Knowing
> > how well that idea would go over (lead balloon is probably an
> > understatement at best) I started looking at what I might be able to
> > remove from the sk_buff struct to make room for a new field (the new
> > field would be a u32).  Looking at the sk_buff structure it appears that
> > the sk_buff.dev and sk_buff.iif fields are a bit redundant and removing
> > the sk_buff.dev field could free 32/64 bits depending on the platform. 
> > Is there any reason (performance?) for keeping the sk_buff.dev field
> > around?  Would the community be open to patches which removed it and
> > transition users over to the sk_buff.iif field?  Finally, assuming the
> > sk_buff.dev field was removed, would the community be open to adding a
> > new LSM/SELinux related u32 field to the sk_buff struct?
>
> This reminds of an idea someone brought up a while ago, it involved
> having a way to attach additional space to an sk_buff for all the
> different marks and other non-essential fields.

Interesting.  Was it just a thought, or was there some actual 
design/code/patchset to go along with it that described the idea?

-- 
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to