From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
virtio-comment@lists.oasis-open.org,
virtio-dev@lists.oasis-open.org, Parav Pandit <parav@nvidia.com>,
Yuri Benditovich <yuri.benditovich@daynix.com>,
Cornelia Huck <cohuck@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: Re: [PATCH v9] virtio-net: support inner header hash
Date: Thu, 23 Feb 2023 08:03:17 -0500 [thread overview]
Message-ID: <20230223075934-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1047920c-5dd5-8f31-0c4c-a108f36155f8@redhat.com>
On Thu, Feb 23, 2023 at 10:50:48AM +0800, Jason Wang wrote:
> Hi:
>
> 在 2023/2/22 14:46, Heng Qi 写道:
> > Hi, Jason. Long time no see. :)
> >
> > 在 2023/2/22 上午11:22, Jason Wang 写道:
> > >
> > > 在 2023/2/22 01:50, Michael S. Tsirkin 写道:
> > > > On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
> > > > > +\subparagraph{Security risks between encapsulated packets and RSS}
> > > > > +There may be potential security risks when encapsulated
> > > > > packets using RSS to
> > > > > +select queues for placement. When a user inside a tunnel
> > > > > tries to control the
> > >
> > >
> > > What do you mean by "user" here? Is it a remote or local one?
> > >
> >
> > I mean a remote attacker who is not under the control of the tunnel
> > owner.
>
>
> Anything may the tunnel different? I think this can happen even without
> tunnel (and even with single queue).
I think you are missing the fact that tunnel is normally a
security boundary: users within the tunnel can not control
what is happening outside.
The feature breaks the encapsulation somewhat.
For example without tunneling it is possible
to create a special "bad guy queue" and direct specific tunnels
there by playing with key and indirection table.
> How to mitigate those attackers seems more like a implementation details
> where might require fair queuing or other QOS technology which has been well
> studied.
>
> It seems out of the scope of the spec (unless we want to let driver
> manageable QOS).
>
> Thanks
>
>
> >
> > Thanks.
> >
> > >
> > > > > +enqueuing of encapsulated packets, then the user can flood
> > > > > the device with invaild
> > > > > +packets, and the flooded packets may be hashed into the
> > > > > same queue as packets in
> > > > > +other normal tunnels, which causing the queue to overflow.
> > > > > +
> > > > > +This can pose several security risks:
> > > > > +\begin{itemize}
> > > > > +\item Encapsulated packets in the normal tunnels cannot be
> > > > > enqueued due to queue
> > > > > + overflow, resulting in a large amount of packet loss.
> > > > > +\item The delay and retransmission of packets in the
> > > > > normal tunnels are extremely increased.
> > > > > +\item The user can observe the traffic information and
> > > > > enqueue information of other normal
> > > > > + tunnels, and conduct targeted DoS attacks.
> > > > > +\end{\itemize}
> > > > > +
> > > > Hmm with this all written out it sounds pretty severe.
> > >
> > >
> > > I think we need first understand whether or not it's a problem that
> > > we need to solve at spec level:
> > >
> > > 1) anything make encapsulated packets different or why we can't hit
> > > this problem without encapsulation
> > >
> > > 2) whether or not it's the implementation details that the spec
> > > doesn't need to care (or how it is solved in real NIC)
> > >
> > > Thanks
> > >
> > >
> > > > At this point with no ways to mitigate, I don't feel this is something
> > > > e.g. Linux can enable. I am not going to nack the spec patch if
> > > > others find this somehow useful e.g. for dpdk.
> > > > How about CC e.g. dpdk devs or whoever else is going to use this
> > > > and asking them for the opinion?
> > > >
> > > >
> >
next prev parent reply other threads:[~2023-02-23 13:03 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-18 14:37 [PATCH v9] virtio-net: support inner header hash Heng Qi
2023-02-20 15:53 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2023-02-20 16:12 ` Michael S. Tsirkin
2023-02-21 4:20 ` Parav Pandit
2023-02-21 6:14 ` [virtio-comment] " Heng Qi
2023-02-21 12:47 ` Parav Pandit
2023-02-21 13:34 ` Heng Qi
2023-02-21 15:32 ` Parav Pandit
2023-02-21 16:44 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2023-02-21 16:50 ` Parav Pandit
2023-02-21 17:13 ` Michael S. Tsirkin
2023-02-21 17:40 ` [virtio-comment] " Parav Pandit
2023-02-21 17:44 ` Michael S. Tsirkin
2023-02-21 17:54 ` Parav Pandit
2023-02-21 17:17 ` [virtio-comment] " Heng Qi
2023-02-21 17:39 ` Parav Pandit
2023-02-21 13:37 ` Heng Qi
2023-02-21 17:05 ` Michael S. Tsirkin
2023-02-21 19:29 ` Parav Pandit
2023-02-21 21:23 ` Michael S. Tsirkin
2023-02-21 21:36 ` Parav Pandit
2023-02-21 21:46 ` Michael S. Tsirkin
2023-02-21 22:32 ` Parav Pandit
2023-02-21 23:18 ` Michael S. Tsirkin
2023-02-22 1:41 ` Parav Pandit
2023-02-22 2:51 ` [virtio-dev] " Heng Qi
2023-02-22 2:34 ` [virtio-dev] " Heng Qi
2023-02-22 6:21 ` Michael S. Tsirkin
2023-02-22 7:03 ` Heng Qi
2023-02-22 11:29 ` Michael S. Tsirkin
2023-03-01 14:32 ` [virtio-dev] " Heng Qi
2023-02-21 17:50 ` Michael S. Tsirkin
2023-02-22 3:22 ` Jason Wang
2023-02-22 6:46 ` Heng Qi
2023-02-22 11:30 ` Michael S. Tsirkin
2023-02-23 2:50 ` Jason Wang
2023-02-23 4:41 ` [virtio-dev] " Heng Qi
2023-02-24 2:45 ` Jason Wang
2023-02-24 4:47 ` [virtio-comment] " Heng Qi
2023-02-24 8:07 ` Michael S. Tsirkin
2023-02-23 13:03 ` Michael S. Tsirkin [this message]
2023-02-24 2:26 ` Jason Wang
2023-02-24 8:06 ` [virtio-dev] " Michael S. Tsirkin
2023-02-27 4:07 ` Jason Wang
2023-02-27 4:07 ` [virtio-dev] " Jason Wang
2023-02-27 7:39 ` Michael S. Tsirkin
2023-02-27 7:39 ` [virtio-dev] " Michael S. Tsirkin
2023-02-27 8:35 ` Jason Wang
2023-02-27 8:35 ` [virtio-dev] " Jason Wang
2023-02-27 12:38 ` Heng Qi
2023-02-27 12:38 ` [virtio-dev] " Heng Qi
2023-02-27 17:49 ` Michael S. Tsirkin
2023-02-27 17:49 ` [virtio-dev] " Michael S. Tsirkin
2023-02-28 3:04 ` Jason Wang
2023-02-28 3:04 ` [virtio-dev] " Jason Wang
2023-02-28 8:52 ` Michael S. Tsirkin
2023-02-28 8:52 ` [virtio-dev] " Michael S. Tsirkin
2023-02-28 9:56 ` Heng Qi
2023-02-28 9:56 ` Heng Qi
2023-02-28 11:04 ` Michael S. Tsirkin
2023-02-28 11:04 ` [virtio-dev] " Michael S. Tsirkin
2023-03-01 2:36 ` Jason Wang
2023-03-01 2:36 ` [virtio-dev] " Jason Wang
2023-03-01 10:36 ` Michael S. Tsirkin
2023-03-02 2:57 ` Jason Wang
2023-03-02 7:42 ` Michael S. Tsirkin
2023-03-02 7:57 ` Jason Wang
2023-03-02 8:09 ` Michael S. Tsirkin
2023-03-02 8:15 ` Jason Wang
2023-03-02 8:41 ` Michael S. Tsirkin
2023-03-02 8:59 ` Jason Wang
2023-03-02 9:46 ` Michael S. Tsirkin
2023-02-23 13:13 ` Michael S. Tsirkin
2023-02-23 14:40 ` [virtio-comment] " Parav Pandit
2023-02-24 8:13 ` Michael S. Tsirkin
2023-02-24 14:38 ` [virtio-dev] " Heng Qi
2023-02-24 17:10 ` Michael S. Tsirkin
2023-02-24 17:10 ` Michael S. Tsirkin
2023-02-27 0:29 ` Parav Pandit
2023-02-27 0:29 ` [virtio-dev] " Parav Pandit
2023-02-24 4:42 ` Heng Qi
2023-02-24 8:04 ` Michael S. Tsirkin
2023-02-28 11:16 ` Michael S. Tsirkin
2023-02-28 11:16 ` [virtio-dev] " Michael S. Tsirkin
2023-03-01 2:56 ` Heng Qi
2023-03-01 2:56 ` Heng Qi
2023-03-08 14:39 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-03-09 4:55 ` Heng Qi
2023-03-09 19:36 ` Michael S. Tsirkin
2023-03-11 3:23 ` Heng Qi
2023-03-15 11:58 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-03-15 12:55 ` Heng Qi
2023-03-15 14:57 ` Michael S. Tsirkin
2023-03-16 13:17 ` Heng Qi
2023-03-20 19:45 ` Michael S. Tsirkin
2023-03-30 12:10 ` Heng Qi
2023-03-20 19:48 ` Michael S. Tsirkin
2023-03-30 12:37 ` Heng Qi
2023-04-08 10:29 ` Michael S. Tsirkin
2023-04-10 13:26 ` Heng Qi
2023-03-01 3:30 ` [virtio-comment] " Heng Qi
2023-03-01 3:30 ` [virtio-dev] " Heng Qi
2023-03-01 11:07 ` Michael S. Tsirkin
2023-03-01 15:10 ` Heng Qi
2023-03-09 12:28 ` [virtio-dev] " Heng Qi
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=20230223075934-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.com \
--cc=yuri.benditovich@daynix.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).