On Thu, Mar 23, 2023 at 10:10:25PM +0800, Cheng Xu wrote: > > > On 3/23/23 9:05 PM, Jason Gunthorpe wrote: > > On Thu, Mar 23, 2023 at 08:33:53PM +0800, Cheng Xu wrote: > >> > >> > >> On 3/23/23 7:53 PM, Jason Gunthorpe wrote: > >>> On Thu, Mar 23, 2023 at 02:57:49PM +0800, Cheng Xu wrote: > >>>> > >>>> > >>>> On 3/22/23 10:01 PM, Jason Gunthorpe wrote: > >>>>> On Wed, Mar 22, 2023 at 09:30:41PM +0800, Cheng Xu wrote: > >>>>>> > >>>>>> > >>>>>> On 3/22/23 7:54 PM, Jason Gunthorpe wrote: > >> <...> > >>>> > >>>> It's much clear, thanks for your explanation and patience. > >>>> > >>>> Back to erdma context, we have rethought our implementation. For QPs, > >>>> we have a field *wqe_index* in SQE/RQE, which indicates the validity > >>>> of the current WQE. Incorrect doorbell value from other processes can > >>>> not corrupt the QPC in hardware due to PI range and WQE content > >>>> validation in HW. > >>> > >>> No, validating the DB content is not acceptable security. The attacker > >>> process can always generate valid content if it tries hard enough. > >>> > >> > >> Oh, you may misunderstand what I said, our HW validates the *WQE* content, > >> not *DB* content. The attacker can not generate the WQE of other QPs. This > >> protection and correction is already implemented in our HW. > > > > Why are you talking about WQEs in a discussion about doorbell > > security? > > Malicious doorbell will corrupt the head pointer in QPC, and then invalid WQEs > will be processed. My point is that WQE validation can correct the head pointer > carried in malicious doorbell, and can prevent such attack. No, if the head pointer is incorrect an attack can stall the QP by guessing a head pointer that is valid but before already submitted WQEs. There is no WQE based recovery for such a thing. Jason
