From: Kees Cook <kees@kernel.org>
To: Kuniyuki Iwashima <kuniyu@amazon.com>
Cc: ahmed.zaki@intel.com, aleksander.lobakin@intel.com,
alex.aring@gmail.com, andrew+netdev@lunn.ch, ardb@kernel.org,
christophe.leroy@csgroup.eu, cratiu@nvidia.com,
d.bogdanov@yadro.com, davem@davemloft.net, decui@microsoft.com,
dianders@chromium.org, ebiggers@google.com, edumazet@google.com,
fercerpav@gmail.com, gmazyland@gmail.com, grundler@chromium.org,
haiyangz@microsoft.com, hayeswang@realtek.com, hch@lst.de,
horms@kernel.org, idosch@nvidia.com, jiri@resnulli.us,
jv@jvosburgh.net, kch@nvidia.com, kuba@kernel.org,
kys@microsoft.com, leiyang@redhat.com,
linux-hardening@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wpan@vger.kernel.org, linux@treblig.org,
martin.petersen@oracle.com, mgurtovoy@nvidia.com,
michael.christie@oracle.com, mingzhe.zou@easystack.cn,
miquel.raynal@bootlin.com, mlombard@redhat.com,
netdev@vger.kernel.org, pabeni@redhat.com, phahn-oss@avm.de,
sagi@grimberg.me, sam@mendozajonas.com, sdf@fomichev.me,
shaw.leon@gmail.com, stefan@datenfreihafen.org,
target-devel@vger.kernel.org, viro@zeniv.linux.org.uk,
wei.liu@kernel.org
Subject: Re: [PATCH 0/7] net: Convert dev_set_mac_address() to struct sockaddr_storage
Date: Tue, 20 May 2025 17:42:32 -0700 [thread overview]
Message-ID: <202505201741.AFA146E7F6@keescook> (raw)
In-Reply-To: <20250521001931.7761-1-kuniyu@amazon.com>
On Tue, May 20, 2025 at 05:19:20PM -0700, Kuniyuki Iwashima wrote:
> From: Kees Cook <kees@kernel.org>
> Date: Tue, 20 May 2025 15:30:59 -0700
> > Hi,
> >
> > As part of the effort to allow the compiler to reason about object sizes,
> > we need to deal with the problematic variably sized struct sockaddr,
> > which has no internal runtime size tracking. In much of the network
> > stack the use of struct sockaddr_storage has been adopted. Continue the
> > transition toward this for more of the internal APIs. Specifically:
> >
> > - inet_addr_is_any()
> > - netif_set_mac_address()
> > - dev_set_mac_address()
> >
> > Only 3 callers of dev_set_mac_address() needed adjustment; all others
> > were already using struct sockaddr_storage internally.
>
> I guess dev_set_mac_address_user() was missed on the way ?
>
> For example, tap_ioctl() still uses sockaddr and calls
> dev_set_mac_address_user(), which cast it to _storage.
Ah yes, I can include that in the next version if you want? I was trying
to find a stopping point since everything kind of touches everything ...
:P
--
Kees Cook
next prev parent reply other threads:[~2025-05-21 0:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 22:30 [PATCH 0/7] net: Convert dev_set_mac_address() to struct sockaddr_storage Kees Cook
2025-05-20 22:31 ` [PATCH 1/7] net: core: Convert inet_addr_is_any() to sockaddr_storage Kees Cook
2025-05-21 0:04 ` Kuniyuki Iwashima
2025-05-21 1:26 ` Martin K. Petersen
2025-05-20 22:31 ` [PATCH 2/7] net: core: Switch netif_set_mac_address() to struct sockaddr_storage Kees Cook
2025-05-20 22:47 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 3/7] net/ncsi: Use struct sockaddr_storage for pending_mac Kees Cook
2025-05-20 22:48 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 4/7] ieee802154: Use struct sockaddr_storage with dev_set_mac_address() Kees Cook
2025-05-20 22:49 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 5/7] net: usb: r8152: Convert to use struct sockaddr_storage internally Kees Cook
2025-05-20 22:49 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 6/7] net: core: Convert dev_set_mac_address() to struct sockaddr_storage Kees Cook
2025-05-20 22:50 ` Gustavo A. R. Silva
2025-05-20 22:31 ` [PATCH 7/7] rtnetlink: do_setlink: Use " Kees Cook
2025-05-20 22:50 ` Gustavo A. R. Silva
2025-05-21 0:19 ` [PATCH 0/7] net: Convert dev_set_mac_address() to " Kuniyuki Iwashima
2025-05-21 0:42 ` Kees Cook [this message]
2025-05-21 3:09 ` Jakub Kicinski
2025-05-21 5:18 ` Kees Cook
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=202505201741.AFA146E7F6@keescook \
--to=kees@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=alex.aring@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=ardb@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=cratiu@nvidia.com \
--cc=d.bogdanov@yadro.com \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=dianders@chromium.org \
--cc=ebiggers@google.com \
--cc=edumazet@google.com \
--cc=fercerpav@gmail.com \
--cc=gmazyland@gmail.com \
--cc=grundler@chromium.org \
--cc=haiyangz@microsoft.com \
--cc=hayeswang@realtek.com \
--cc=hch@lst.de \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=jiri@resnulli.us \
--cc=jv@jvosburgh.net \
--cc=kch@nvidia.com \
--cc=kuba@kernel.org \
--cc=kuniyu@amazon.com \
--cc=kys@microsoft.com \
--cc=leiyang@redhat.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=linux@treblig.org \
--cc=martin.petersen@oracle.com \
--cc=mgurtovoy@nvidia.com \
--cc=michael.christie@oracle.com \
--cc=mingzhe.zou@easystack.cn \
--cc=miquel.raynal@bootlin.com \
--cc=mlombard@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=phahn-oss@avm.de \
--cc=sagi@grimberg.me \
--cc=sam@mendozajonas.com \
--cc=sdf@fomichev.me \
--cc=shaw.leon@gmail.com \
--cc=stefan@datenfreihafen.org \
--cc=target-devel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wei.liu@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox