All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Maxim Georgiev <glipus@gmail.com>,
	kory.maincent@bootlin.com, netdev@vger.kernel.org,
	maxime.chevallier@bootlin.com
Subject: Re: [PATCH net-next RFC] Add NDOs for hardware timestamp get/set
Date: Sat, 1 Apr 2023 12:14:51 -0700	[thread overview]
Message-ID: <20230401121451.4457de9c@kernel.org> (raw)
In-Reply-To: <20230401182058.zt5qhgjmejm7lnst@skbuf>

On Sat, 1 Apr 2023 21:20:58 +0300 Vladimir Oltean wrote:
> > After this patch we'll be passing an in-kernel-space struct to drivers
> > rather than the ifr they have to copy themselves. I'm saying that we
> > should validate that exact copy, rather than copy, validate, copy, pass
> > to drivers, cause user space may change the values between the two
> > copies.
> > 
> > Unlikely to cause serious bugs but seems like a good code hygiene.
> > 
> > This is only for the drivers converted to the NDO, obviously, 
> > the legacy drivers will still have to copy themselves.  
> 
> Could you answer my second paragraph too, please?
> 
> | Perhaps I don't understand what is it that can change the contents
> | of the ifreq structure, which would make this a potential issue for
> | ndo_hwtstamp_set() that isn't an issue for ndo_eth_ioctl()...
> 
> I don't disagree with minimizing the number of copy_to_user() calls, but
> I don't understand the ToCToU argument that you're bringing....

As I said, just code hygiene, I haven't looked at the drivers.
Seems too obvious to invest time trying to come up with an exact
scenario.

Do you see a reason not to code this the right way?

  parent reply	other threads:[~2023-04-01 19:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31  4:56 [PATCH net-next RFC] Add NDOs for hardware timestamp get/set Maxim Georgiev
2023-03-31  5:35 ` Jakub Kicinski
2023-03-31 17:51   ` Max Georgiev
2023-03-31 18:10     ` Jakub Kicinski
2023-04-01 18:16       ` Vladimir Oltean
2023-04-01 19:12       ` Vladimir Oltean
2023-04-01 19:24         ` Jakub Kicinski
2023-04-01 19:30           ` Vladimir Oltean
2023-04-01 20:18           ` Vladimir Oltean
2023-04-02 14:28             ` Max Georgiev
2023-04-02 16:56               ` Vladimir Oltean
2023-04-01 16:08   ` Vladimir Oltean
2023-04-01 17:55     ` Jakub Kicinski
2023-04-01 18:20       ` Vladimir Oltean
2023-04-01 18:22         ` Vladimir Oltean
2023-04-01 19:14         ` Jakub Kicinski [this message]
2023-04-01 19:19           ` Vladimir Oltean

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=20230401121451.4457de9c@kernel.org \
    --to=kuba@kernel.org \
    --cc=glipus@gmail.com \
    --cc=kory.maincent@bootlin.com \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=vladimir.oltean@nxp.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.