All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Cc: David Miller <davem@davemloft.net>,
	Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH RFC net-next] packet: always ensure that we pass hard_header_len bytes in skb_headlen() to the driver
Date: Fri, 27 Jan 2017 10:28:16 -0500	[thread overview]
Message-ID: <CAF=yD-+LS6g572Uo5oErq7uazxxPwXXo0w2p4zcHDbXxkuah6Q@mail.gmail.com> (raw)
In-Reply-To: <20170127151119.GB25829@oracle.com>

> " The AX.25 device level drivers are simply written to be robust if
>   thrown partial frames.
>    :
>   The other thing that concerns me about this added logic in general is
>   that you are also breaking test tools that want to deliberately send
>   corrupt frames to certain classes of interface."
>
> But how does the driver (even a robust one!) compute the L2 dst/src if the
> application has not even passed down the minimum (which is 21 for ax25?)

Perhaps the goal is to test that the driver gracefully handles such
packets. I can only speculate.

> Would it make sense to only do the CAP_SYS_RAWIO branch if the
> driver declares itself to have variable length L2 headers, via, e.g.,
> some priv flag?

At the time, the comments were not specific to AX25. Again, we should
probably put that bypass behind a flag, enabling validating in the common case.

> BTW the http://comments.gmane.org/gmane.linux.network/401064 referred
> to in commit 2793a23 is not accessible any more, not sure if its contents
> were the same as the link you just shared.

It is. I looked it up in my email archive. Too bad that that seems to
be the only way.

  reply	other threads:[~2017-01-27 15:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24 16:11 [PATCH RFC net-next] packet: always ensure that we pass hard_header_len bytes in skb_headlen() to the driver Sowmini Varadhan
2017-01-25 17:45 ` David Miller
2017-01-26 20:21 ` Willem de Bruijn
2017-01-26 21:37   ` Sowmini Varadhan
2017-01-27  0:08     ` Willem de Bruijn
2017-01-27  2:08       ` Sowmini Varadhan
2017-01-27 14:37         ` Willem de Bruijn
2017-01-27 15:11           ` Sowmini Varadhan
2017-01-27 15:28             ` Willem de Bruijn [this message]
2017-01-27 17:03               ` Sowmini Varadhan
2017-01-27 19:29                 ` Willem de Bruijn
2017-01-27 20:06                   ` Sowmini Varadhan
2017-01-27 20:51                     ` Willem de Bruijn
2017-01-27 21:58                       ` Sowmini Varadhan
2017-01-28  0:19                         ` Willem de Bruijn
2017-01-30 16:26                           ` Sowmini Varadhan
2017-01-30 16:41                             ` David Miller
2017-02-07 20:51                               ` Willem de Bruijn

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='CAF=yD-+LS6g572Uo5oErq7uazxxPwXXo0w2p4zcHDbXxkuah6Q@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=sowmini.varadhan@oracle.com \
    /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.