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 - 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
