[RFC] Wild and crazy ideas involving struct sk_buff

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

Over in LSM/SELinux land there has been a lot of talk recently about how to 
deal with loopback and forwarded traffic, specifically, how to preserve the 
sender's security label on those two types of traffic.  Yes, there is the 
existing sk_buff.secmark field but that is already being used for something 
else and utilizing it for this purpose has it's pros/cons.

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?

Thanks.
 
-- 
paul moore
linux security @ hp