Messages in this thread | | | From | Willem de Bruijn <> | Date | Tue, 8 Sep 2020 13:52:38 +0200 | Subject | Re: Question about dev_validate_header used in af_packet.c |
| |
On Tue, Sep 8, 2020 at 1:04 PM Xie He <xie.he.0141@gmail.com> wrote: > > On Tue, Sep 8, 2020 at 1:41 AM Willem de Bruijn > <willemdebruijn.kernel@gmail.com> wrote: > > > > 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 > > failing. > > > > > 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. > > OK. I got what you mean. You don't want to make people's test cases fail. > > I was recently looking at some drivers, and I felt that if af_packet.c > could help me filter out the invalid RAW frames, I didn't need to > check the validity of the frames myself (in the driver when > transmitting). But now I guess I still need to check that. > > I feel this makes the dev_validate_header's variable-length header > check not very useful, because drivers need to do this check again > (when transmitting) anyway. > > I was thinking, after I saw dev_validate_header, that we could > eventually make it completely take over the responsibility for a > driver to validate the header when transmitting RAW frames. But now it > seems we would not be able to do this.
Agreed. As is, it is mainly useful to block users who are ns_capable, but not capable.
A third option is to move it behind a sysctl (with static_branch). Your point is valid that there really is no need for testing of drivers against bad packets if the data is validated directly on kernel entry.
| |