[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJht_EP=g02o2ygihNo=EWd1OuL3HSjmhqgGiwUGrMde=urSUA@mail.gmail.com>
Date: Sat, 5 Sep 2020 16:20:49 -0700
From: Xie He <xie.he.0141@...il.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Eric Dumazet <eric.dumazet@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Question about dev_validate_header used in af_packet.c
On Sat, Sep 5, 2020 at 3:24 PM Xie He <xie.he.0141@...il.com> 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
them?)
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?)
Thanks!
Powered by blists - more mailing lists