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

[Junxian Huang <huangjunxian6@hisilicon.com>]

On 2025/4/1 21:39, Jason Gunthorpe wrote:
> 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.
> 

Thanks, we'll try this way.

Junxian

> Jason