OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [PATCH v9] virtio-net: support inner header hash


On Fri, Feb 24, 2023 at 12:42:40PM +0800, Heng Qi wrote:
> 
> 
> å 2023/2/23 äå9:13, 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.
> > Is this just with RSS? I assume hash calculation is also used for
> > something like queueing so there's a similar risk even just
> > with hash reporting, no?
> 
> I don't understand why it would be risky to just report hash when not used
> for queuing,
> and even we don't report whether hash come from inner or outer now because
> there is no more hash_report_tunnel.

Well what is the hash used for? Presumably it's used for queueing within
driver, no? Collisions there then have exactly the same effect as queue
collisions in the device.

> > 
> > > When a user inside a tunnel tries to control the
> > > +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}
> > > +
> > 
> > So for RSS specifically, we brain-stormed with Amnon (Cc'd) and came
> > up with an idea: RSS indirection table entries are 16 bit but
> > onlu 15 bits are used to indentify an RX queue.
> > We can use the remaining bit as a "tunnel bit" to signal whether to use the
> > inner or the outer hash for queue selection.
> > 
> > The lookup will work like this then:
> > 
> > calculate outer hash
> > if (rss[outer hash] & tunnel bit)
> 
> How a tunnel bit distinguishes between multiple tunnel types, and I think it
> is not so reasonable to use the
> indirection table to determine the switch of the inner hash. The inner hash
> is only the ability to calculate the hash,
> and does not involve the indirection table.
> 
> Thanks.
> 
> > then
> > 	calculate inner hash
> > 	return rss[inner hash] & ~tunnel bit
> > else
> > 	return rss[outer hash]
> > 
> > 
> > this fixes the security issue returning us back to
> > status quo : specific tunnels can be directed to separate queues.
> > 
> > 
> > This is for RSS.
> > 
> > 
> > For hash reporting indirection table is not used.
> > Maybe it is enough to signal to driver that inner hash was used.
> > We do need that signalling though.
> > 
> > My question would be whether it's practical to implement in hardware.
> > 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]