Netdev Archive on
help / color / mirror / Atom feed
From: Xie He <>
To: Willem de Bruijn <>,
	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: Sat, 5 Sep 2020 16:20:49 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sat, Sep 5, 2020 at 3:24 PM Xie He <> wrote:
> Hi Willem,
> I have a question about the function dev_validate_header used in
> af_packet.c. Can you help me? Thanks!
> I see when the length of the data is smaller than hard_header_len, and
> when the user is "capable" enough, the function will accept it and pad
> it with 0s, without validating the header with header_ops->validate.
> But I think if the driver is able to accept variable-length LL
> headers, shouldn't we just pass the data to header_ops->validate and
> let it check the header's validity, and then just pass the validated
> data to the driver for transmission?
> Why when the user is "capable" enough, can it bypass the
> header_ops->validate check? And why do we need to pad the data with
> 0s? Won't this make the driver confused about the real length of the
> data?

Oh. I just realized that the padding of zeros won't actually make the
data longer. The padded zeros are not part of the data so the length
of the data is kept unchanged. The padding is probably because some
weird drivers are expecting this. (What drivers are them? Can we fix

I can also understand now the ability of a "capable" user to bypass
the header_ops->validate check. It is probably for testing purposes.
(Does this mean the root user will always bypass this check?)


  reply	other threads:[~2020-09-05 23:21 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 [this message]
2020-09-07  9:05   ` Willem de Bruijn
2020-09-07 21:16     ` Xie He
2020-09-08  8:40       ` Willem de Bruijn
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 \
    --in-reply-to='' \ \ \ \ \ \ \ \

* 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).