From: Paul Moore <paul.moore@hp.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC] Wild and crazy ideas involving struct sk_buff
Date: Wed, 22 Aug 2007 17:26:36 -0400 [thread overview]
Message-ID: <200708221726.36783.paul.moore@hp.com> (raw)
In-Reply-To: <20070822212005.GR32236@postel.suug.ch>
On Wednesday, August 22 2007 5:20:05 pm Thomas Graf wrote:
> * Paul Moore <paul.moore@hp.com> 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
next prev parent reply other threads:[~2007-08-22 21:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-22 20:31 [RFC] Wild and crazy ideas involving struct sk_buff Paul Moore
2007-08-22 21:08 ` David Miller
2007-08-22 21:23 ` Paul Moore
2007-08-22 21:20 ` Thomas Graf
2007-08-22 21:26 ` Paul Moore [this message]
2007-08-22 21:36 ` David Miller
2007-08-22 22:06 ` Arnaldo Carvalho de Melo
2007-08-22 22:09 ` James Morris
2007-08-22 22:20 ` Paul Moore
2007-08-22 22:31 ` James Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200708221726.36783.paul.moore@hp.com \
--to=paul.moore@hp.com \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.