Netdev Archive on
help / color / mirror / Atom feed
From: Willem de Bruijn <>
To: Xie He <>
Cc: Eric Dumazet <>,
	"David S. Miller" <>,
	Jakub Kicinski <>,
	Linux Kernel Network Developers <>,
	LKML <>
Subject: Re: Question about dev_validate_header used in af_packet.c
Date: Tue, 8 Sep 2020 10:40:28 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Sep 7, 2020 at 11:17 PM Xie He <> wrote:
> On Mon, Sep 7, 2020 at 2:06 AM Willem de Bruijn
> <> wrote:
> >
> > The CAP_SYS_RAWIO exception indeed was requested to be able to
> > purposely test devices against bad inputs. The gmane link
> > unfortunately no longer works, but this was the discussion thread:
> >
> >
> > It zeroes the packet up max_header_len to ensure that an unintentional
> > short packet will at least not result in reading undefined data. Now
> > that the dust has settled around the min_header_len/max_header_len
> > changes, maybe now is a good time to revisit removing that
> > CAP_SYS_RAWIO loophole.
> Thank you for your explanation! I can now understand the logic of
> dev_hard_header. Thanks!
> Do you mean we can now consider removing the ability to bypass the
> header_ops->validate check? That is what I am thinking about, too!
> I looked at the link you gave me. I see that Alan Cox wanted to keep
> the ability of intentionally feeding corrupt frames to drivers, to
> test whether drivers are able to handle incomplete headers. However, I
> think after we added the header validation in af_packet.c, drivers no
> longer need to ensure they can handle incomplete headers correctly
> (because this is already handled by us).

Which header validation are you referring to?

The intent is to bypass such validation to be able to test device
drivers. Note that removing that may cause someone's test to start

>  So there's no point in
> keeping the ability to test this, either.

I don't disagree in principle, but do note the failing tests. Bar any
strong reasons for change, I'd leave as is.

  reply	other threads:[~2020-09-08  8:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-05 22:24 Question about dev_validate_header used in af_packet.c Xie He
2020-09-05 23:20 ` Xie He
2020-09-07  9:05   ` Willem de Bruijn
2020-09-07 21:16     ` Xie He
2020-09-08  8:40       ` Willem de Bruijn [this message]
2020-09-08 11:00         ` Xie He
2020-09-08 11:52           ` Willem de Bruijn
2020-09-08 12:45             ` Xie He
2020-09-08 17:08               ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).