From: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Oren Laadan <orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
Subject: Re: [PATCH 1/3] Record and restore skb header marks (v2)
Date: Tue, 10 Nov 2009 10:18:57 -0800 [thread overview]
Message-ID: <873a4mkzu6.fsf@caffeine.danplanet.com> (raw)
In-Reply-To: <4AE9F6BA.8050601-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org> (Oren Laadan's message of "Thu\, 29 Oct 2009 16\:10\:34 -0400")
Eesh, I just realized I never replied to this mail. Sorry about
that.
OL> I wonder if the sanity test for mac_len and hdr_len are
OL> sufficient, or whether a more constrained test is required.
Yep, I have it changed now, along with some of the other checks.
OL> The skb->cb holds can be used by any layer to put private
OL> variables.
OL> Can the user mangle the data in there to create a disaster of some
OL> sort ?
OL> If the answer is "it's possible", and because this is per protocol
OL> data, I suggest to add a per-protocol callback to sanitize the
OL> data in this control buffer.
Okay, then my answer is "it could be possible later". Right now, I
don't think there's anything in there that could be used to do more
harm than any of the other things we restore for TCP. We don't
restore it for UNIX sockets.
OL> To not block this patchset infinitely, I guess you can put the
OL> details of the sanity check in a separate patch(set). But I prefer
OL> that the current set will at least mention and provision for such
OL> a mechanism.
Indeed. I've added a lengthy comment to be included in the next
posting to cover it for now.
--
Dan Smith
IBM Linux Technology Center
email: danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
next prev parent reply other threads:[~2009-11-10 18:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-27 17:53 Add support for connected AF_INET sockets Dan Smith
[not found] ` <1256666008-8231-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-10-27 17:53 ` [PATCH 1/3] Record and restore skb header marks (v2) Dan Smith
[not found] ` <1256666008-8231-2-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-10-29 20:10 ` Oren Laadan
[not found] ` <4AE9F6BA.8050601-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
2009-11-10 18:18 ` Dan Smith [this message]
2009-10-27 17:53 ` [PATCH 3/3] Add some content to the readme.txt for socket c/r Dan Smith
2009-10-27 17:53 ` [PATCH 2/3] [RFC] Add c/r support for connected INET sockets (v3) Dan Smith
2009-10-29 20:15 ` Oren Laadan
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=873a4mkzu6.fsf@caffeine.danplanet.com \
--to=danms-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org \
/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.