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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Mar 18, 2025 at 11:23:57AM +0800, Junxian Huang wrote:
> Hi Leon and Jason. After discussions and analysis with our FW team,
> we've agreed that FW can stop HW to prevent HW UAF in most FW reset
> cases.
> 
> But there's still one case where FW cannot intervene when FW reset
> is triggered by watchdog due to FW crash, because it is completely
> passive for FW. So we still need these patches to prevent this
> unlikely but still possible HW UAF case. Is this series okay to be
> applied?

You need to have an architecture where there are clear rules about
when HW is allowed to access DMA memory and when it is not, then
implement accordingly. Most devices have a hard reset which is a
strong barrier preventing DMA from crossing it. You need something
similar.

For things like mbox failures/timeouts, a timeout means the SW cannot
assume the devices is no longer doing DMA. It would be appropriate to
immediately trigger the reset sequence, wait for it to reach the
barrier, then conclude and error the mbox.

This way this:

> > 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.

Changes "destruction fail" into a barrier that waits for the device to
be fenced and DMA to be halted before returning keeping the driver
life cycle together.

You want to avoid "destruction fail" paths that result in the device
continuing to function.

Jason