All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <oliver@hartkopp.net>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, Wolfgang Grandegger <wg@grandegger.com>
Subject: Re: [RFC] ndo_validate_skb: Let the netdev check a valid skb content
Date: Thu, 07 Jan 2010 18:50:35 +0100	[thread overview]
Message-ID: <4B461EEB.7040806@hartkopp.net> (raw)
In-Reply-To: <20100107.004101.217821816.davem@davemloft.net>

David Miller wrote:
> From: Oliver Hartkopp <oliver@hartkopp.net>
> Date: Wed, 23 Dec 2009 20:23:27 +0100
> 
>> @@ -2034,6 +2035,14 @@ int dev_queue_xmit(struct sk_buff *skb)
>>  			goto out_kfree_skb;
>>  	}
>>  
>> +	/* If the device offers a function to validate the skb content, let
>> +	 * it check the skb and return an error to the caller if it fails.
>> +	 */ 
>> +	if (ops->ndo_validate_skb && ops->ndo_validate_skb(skb)) {
>> +		rc = -EINVAL;
>> +		goto out_kfree_skb;
>> +	}
>> +
> 
> To me this is as valuable as no error at all and simply having
> the driver drop the frame.  Which is what we do now.  I can
> sniff at the receiver to see that the device never transmitted
> the frame.
> 
> Is this getting this generic -EINVAL back so important that it's
> worth adding the new if() test for the NULL method to every packet
> that traverses the machine?  Keep in mind we can route at rates
> exceeding 1 million packets per second, so ever cycle you add
> here really matters.
> 
> If you want to place the hooks still, put them out of the fast
> path, which is probably in AF_PACKET.  We can extend this to
> call the validation function from other "untrusted" sources.
> 
> But do realize that you're not saving anything, things like
> queueing disciplines and traffic classifiers in the qdisc
> layer can modify any part of the packet however they wish.
> 
> So even if the CAN protocol layer itself emitted a valid
> frame, the qdisc layer can "corrupt" it.

I see. Thanks for your detailed answer!

Indeed silently drop the invalid CAN frame inside the driver (and increase
dev->stats.tx_dropped) looks like the best solution to me now.

If people try to push rubbish into the device, tx_dropped is an appropriate
indication.

Thanks,
Oliver


      reply	other threads:[~2010-01-07 17:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-23 19:23 [RFC] ndo_validate_skb: Let the netdev check a valid skb content Oliver Hartkopp
2010-01-07  8:41 ` David Miller
2010-01-07 17:50   ` Oliver Hartkopp [this message]

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=4B461EEB.7040806@hartkopp.net \
    --to=oliver@hartkopp.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=wg@grandegger.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.