Re: [PATCH for-next 0/4] RDMA/hns: Introduce delay-destruction mechanism

[Leon Romanovsky <leon@kernel.org>]

On Thu, Feb 20, 2025 at 11:48:49AM +0800, Junxian Huang wrote:
> 
> 
> On 2025/2/19 22:35, Leon Romanovsky wrote:
> > On Wed, Feb 19, 2025 at 09:07:36PM +0800, Junxian Huang wrote:
> >>
> >>
> >> On 2025/2/19 20:14, Leon Romanovsky wrote:
> >>> On Mon, Feb 17, 2025 at 03:01:19PM +0800, Junxian Huang wrote:
> >>>> When mailboxes for resource(QP/CQ/SRQ) destruction fail, it's unable
> >>>> to notify HW about the destruction. In this case, driver will still
> >>>> free the resources, while HW may still access them, thus leading to
> >>>> a UAF.
> >>>
> >>>> This series introduces delay-destruction mechanism to fix such HW UAF,
> >>>> including thw HW CTX and doorbells.
> >>>
> >>> And why can't you fix FW instead?
> >>>
> >>
> >> The key is the failure of mailbox, and there are some cases that would
> >> lead to it, which we don't really consider as FW bugs.
> >>
> >> For example, when some random fatal error like RAS error occurs in FW,
> >> our FW will be reset. Driver's mailbox will fail during the FW reset.
> > 
> > I don't understand this scenario. You said at the beginning that HW can
> > access host memory and this triggers UAF. However now, you are presenting 
> > case where driver tries to access mailbox.
> > 
> 
> No, I'm saying that mailbox errors are the reason of HW UAF. Let me
> explain this scenario in more detail.
> 
> Driver notifies HW about the memory release with mailbox. The procedure
> of a mailbox is:
> 	a) driver posts the mailbox to FW
> 	b) FW writes the mailbox data into HW
> 
> In this scenario, step a) will fail due to the FW reset, HW won't get
> notified and thus may lead to UAF.

Exactly, FW performed reset and didn't prevent from HW to access it.

Thanks

> 
> Junxian
> 
> >>
> >> Another case is the mailbox timeout when FW is under heavy load, as it is
> >> shared by multi-functions.
> > 
> > It is not different from any other mailbox errors. FW needs to handle
> > these cases.
> > 
> > Thanks
> > 
> >>
> >> Thanks,
> >> Junxian
> >>
> >>> Thanks