Re: [virtio-dev] Re: [virtio-comment] Re: [PATCH v12] virtio-net: support inner header hash

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Apr 14, 2023 at 11:56:05AM +0800, Heng Qi wrote:
> 
> 
> 在 2023/4/14 上午5:43, Michael S. Tsirkin 写道:
> > On Thu, Apr 13, 2023 at 07:03:26PM +0800, Heng Qi wrote:
> > > > >    For example, when the packets of certain
> > > > > +tunnels are spread across multiple receive queues, these receive
> > > > > queues may have an unbalanced
> > > > > +amount of packets. This can cause a specific receive queue to
> > > > > become full, resulting in packet loss.
> > > > 
> > > > We have many places that can lead to packet dropping. For example, the
> > > > automatic steering is best effort. I tend to avoid mentioning things
> > > > like this.
> > > Ok. And Michael what do you think about this?
> > 
> > I think this text did not do a great job explaining the
> > security aspect. Here's a better, shorter explanation:
> > 
> > 	It is often an expectation of users that a tunnel isolates the external
> > 	network from the internal one. By completely ignoring entropy in the
> > 	external header and replacing it with entropy from the internal header,
> > 	for hash calculations, this expectation might be violated to a certain
> > 	extent, depending on how the hash is used. When the hash use is limited
> > 	to RSS queue selection, the effect will likely be limited to ability of
> > 	users inside the tunnel to cause packet drops in multiple queues (as
> > 	opposed to a single queue without the feature).
> 
> Sure. Will do  in the v13.
> 
> > 
> > > > 
> > > > > +
> > > > > +Possible mitigations:
> > > > > +\begin{itemize}
> > > > > +\item Use a tool with good forwarding performance to keep the
> > > > > receive queue from filling up.
> > > > > +\item If the QoS is unavailable, the driver can set
> > > > > \field{hash_tunnel_types} to VIRTIO_NET_HASH_TUNNEL_TYPE_NONE
> > > > > +      to disable inner header hash for encapsulated packets.
> > > > > +\item Choose a hash key that can avoid queue collisions.
> > > > > +\item Perform appropriate QoS before packets consume the receive
> > > > > buffers of the receive queues.
> > > > > +\end{itemize}
> > > > > +
> > > > > +The limitations mentioned above exist with/without the inner header
> > > > > hash.
> > > > 
> > > > This conflicts with the tile "Tunnel QoS limitation" which readers may
> > > > think it happens only for tunnel.
> > > Perhaps a "QoS Advices" is better?
> > Plural of "advice" is "advice" not "advices".
> 
> My fault.😅
> 
> > 
> > This advice is somewhat bogus though.
> > 
> > The point I keep trying to make is that this:
> > 
> > 	Choose a hash key that can avoid queue collisions.
> > 
> > is impossible with the feature and possible without.
> 
> I don't think so, the outer headers also has corresponding entropy for
> different streams.

But the feature when enabled ignores this entropy.

> Thanks.
> 
> > This was the whole reason I asked for a security
> > considerations sections.
> > 
> > 
> > > Thanks!
> > > 
> > > > Thanks
> > > > 
> > > > 
> > > > This publicly archived list offers a means to provide input to the
> > > > OASIS Virtual I/O Device (VIRTIO) TC.
> > > > 
> > > > In order to verify user consent to the Feedback License terms and
> > > > to minimize spam in the list archive, subscription is required
> > > > before posting.
> > > > 
> > > > Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> > > > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> > > > List help: virtio-comment-help@lists.oasis-open.org
> > > > List archive: https://lists.oasis-open.org/archives/virtio-comment/
> > > > Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> > > > List Guidelines:
> > > > https://www.oasis-open.org/policies-guidelines/mailing-lists
> > > > Committee: https://www.oasis-open.org/committees/virtio/
> > > > Join OASIS: https://www.oasis-open.org/join/
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org