From: Rahul Rameshbabu <rrameshbabu@nvidia.com>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: netdev@vger.kernel.org, stable@vger.kernel.org,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>, Gal Pressman <gal@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>,
Yossi Kuperman <yossiku@nvidia.com>,
Benjamin Poirier <bpoirier@nvidia.com>,
Cosmin Ratiu <cratiu@nvidia.com>
Subject: Re: [PATCH net-next 2/3] macsec: Detect if Rx skb is macsec-related for offloading devices that update md_dst
Date: Mon, 22 Apr 2024 22:55:02 -0700 [thread overview]
Message-ID: <87plugpqrk.fsf@nvidia.com> (raw)
In-Reply-To: <ZiYseYT62ZI0-_V9@hog>
On Mon, 22 Apr, 2024 11:23:05 +0200 Sabrina Dubroca <sd@queasysnail.net> wrote:
> 2024-04-19, 11:01:20 -0700, Rahul Rameshbabu wrote:
>> On Fri, 19 Apr, 2024 17:05:52 +0200 Sabrina Dubroca <sd@queasysnail.net> wrote:
>> > 2024-04-18, 18:17:16 -0700, Rahul Rameshbabu wrote:
>> <snip>
>> >> + /* This datapath is insecure because it is unable to
>> >> + * enforce isolation of broadcast/multicast traffic and
>> >> + * unicast traffic with promiscuous mode on the macsec
>> >> + * netdev. Since the core stack has no mechanism to
>> >> + * check that the hardware did indeed receive MACsec
>> >> + * traffic, it is possible that the response handling
>> >> + * done by the MACsec port was to a plaintext packet.
>> >> + * This violates the MACsec protocol standard.
>> >> + */
>> >> + DEBUG_NET_WARN_ON_ONCE(true);
>> >
>> > If you insist on this warning (and I'm not convinced it's useful,
>> > since if the HW is already built and cannot inform the driver, there's
>> > nothing the driver implementer can do), I would move it somewhere into
>> > the config path. macsec_update_offload would be a better location for
>> > this kind of warning (maybe with a pr_warn (not limited to debug
>> > configs) saying something like "MACsec offload on devices that don't
>> > support md_dst are insecure: they do not provide proper isolation of
>> > traffic"). The comment can stay here.
>> >
>>
>> I do not like the warning either. I left it mainly if it needed further
>> discussion on the mailing list. Will remove it in my next revision. That
>> said, it may make sense to advertise rx_uses_md_dst over netlink to
>> annotate what macsec offload path a device uses? Just throwing out an
>> idea here.
>
> Maybe. I was also thinking about adding a way to restrict offloading
> only to devices with rx_uses_md_dst.
That's an option. Basically, devices that do not support rx_uses_md_dst
really only just do SW MACsec but do not return an error if the offload
parameter is passed over netlink so user scripts do not break?
>
> (Slightly related) I also find it annoying that users have to tell the
> kernel whether to use PHY or MAC offload, but have no way to know
> which one their HW supports. That should probably have been an
> implementation detail that didn't need to be part of uapi :/
We could leave the phy / mac netlink keywords and introduce an "on"
option. We deduce whether the device is a phydev or not when on is
passed and set the macsec->offload flag based on that. The phy and mac
options for offload in ip-macsec can then be deprecated.
--
Thanks,
Rahul Rameshbabu
next prev parent reply other threads:[~2024-04-23 5:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 1:17 [PATCH net-next 0/3] Resolve security issue in MACsec offload Rx datapath Rahul Rameshbabu
2024-04-19 1:17 ` [PATCH net-next 1/3] macsec: Enable devices to advertise whether they update sk_buff md_dst during offloads Rahul Rameshbabu
2024-04-19 1:17 ` [PATCH net-next 2/3] macsec: Detect if Rx skb is macsec-related for offloading devices that update md_dst Rahul Rameshbabu
2024-04-19 15:05 ` Sabrina Dubroca
2024-04-19 18:01 ` Rahul Rameshbabu
2024-04-22 9:23 ` Sabrina Dubroca
2024-04-23 5:55 ` Rahul Rameshbabu [this message]
2024-04-24 10:18 ` Sabrina Dubroca
2024-04-19 1:17 ` [PATCH net-next 3/3] net/mlx5e: Advertise mlx5 ethernet driver updates sk_buff md_dst for MACsec Rahul Rameshbabu
2024-04-19 15:04 ` [PATCH net-next 0/3] Resolve security issue in MACsec offload Rx datapath Sabrina Dubroca
2024-04-19 17:56 ` Rahul Rameshbabu
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=87plugpqrk.fsf@nvidia.com \
--to=rrameshbabu@nvidia.com \
--cc=bpoirier@nvidia.com \
--cc=cratiu@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=stable@vger.kernel.org \
--cc=tariqt@nvidia.com \
--cc=yossiku@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).