netdev - Re: [RFC] Wild and crazy ideas involving struct sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200708221723.41802.paul.moore@hp.com>
Date:	Wed, 22 Aug 2007 17:23:41 -0400
From:	Paul Moore <paul.moore@...com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, jmorris@...ei.org
Subject: Re: [RFC] Wild and crazy ideas involving struct sk_buff

On Wednesday, August 22 2007 5:08:05 pm David Miller wrote:
> From: Paul Moore <paul.moore@...com>
> Date: Wed, 22 Aug 2007 16:31:34 -0400
>
> > 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?
>
> It's there for performance, and I bet there might be some semantic
> issues involved.

Okay, thought that was probably the case considering the efforts to shrink the 
sk_buff as much as possible.

> And ironically James Morris still owes me a struct sk_buff removal
> from when I let him put the "secmark" thing in there!
>
> Stop spending money you guys haven't earned yet :-)

Hey, I was just asking how much it cost ... but then again, you know the old 
adage, "if you have to ask, you can't afford it" ;)

Thanks.

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