From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45185C6FD1C for ; Thu, 23 Mar 2023 06:58:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230310AbjCWG6S (ORCPT ); Thu, 23 Mar 2023 02:58:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230293AbjCWG6S (ORCPT ); Thu, 23 Mar 2023 02:58:18 -0400 Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEC197A87 for ; Wed, 22 Mar 2023 23:58:02 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R791e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046049;MF=chengyou@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0VeTMz1Y_1679554672; Received: from 30.221.102.45(mailfrom:chengyou@linux.alibaba.com fp:SMTPD_---0VeTMz1Y_1679554672) by smtp.aliyun-inc.com; Thu, 23 Mar 2023 14:57:52 +0800 Message-ID: <8c446431-9f86-7267-6051-9c016e23215e@linux.alibaba.com> Date: Thu, 23 Mar 2023 14:57:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH for-next v2 2/2] RDMA/erdma: Support non-4K page size in doorbell allocation Content-Language: en-US To: Jason Gunthorpe Cc: Leon Romanovsky , linux-rdma@vger.kernel.org, KaiShen@linux.alibaba.com, Yossi Leybovich , Gal Pressman References: <20230307102924.70577-3-chengyou@linux.alibaba.com> <20230314102313.GB36557@unreal> <20230314141020.GL36557@unreal> <1604d654-583f-52eb-ff76-fd92647d3625@linux.alibaba.com> <20230315102210.GT36557@unreal> <2c82439c-15d0-d5dd-b1c5-46053d3dd202@linux.alibaba.com> <6c982b76-61b2-7317-ab76-8ff0b4fb4471@linux.alibaba.com> From: Cheng Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org 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: >>> On Wed, Mar 22, 2023 at 03:05:29PM +0800, Cheng Xu wrote: >>> >>>> The current generation of erdma devices do not have this capability due to >>>> implementation complexity. Without this HW capability, isolating the MMIO >>>> space in software doesn't prevent the attack, because the malicious APPs >>>> can map mmio itself, not through verbs interface. >>> >>> This doesn't meet the security model of Linux, verbs HW is expected to >>> protect one process from another process. >> >> OK, I see. >> >> So the key point is that HW should restrict each process to use its own doorbell >> space. If hardware can do this, share or do not share MMIO pages both will meet >> the security requirement. Do I get it right? > > HW can never do that, HW is supposed to rely on the system MMU to > isolate doorbell registers > > The HW responsibility is to make doorbell MMIO registers safe in the > hands of other processes. > > Simple doorbells that only 'kick' and don't convey any information are > probably safe to share, and don't require HW checks between the > doorbell page and the PD/QP/CQ/etc > > Doorbells that deliver data - eg a head pointer - are not safe because > the wrong head pointer can corrupt the HW state. Process B must not be > able to corrupt the head pointer of a QP/CQ owned by Process A under > any circumstances. Definitely they cannot have access to the MMIO and > also the HW must ensure that writes coming from process B are rejected > if they touch resources owned by process a (eg by PD/QPN/CQN checks in > HW) > > Doorbells that accept entire WQE's are definately not safe as a > hostile process could execute a WQE on a QP it does not own. > 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. Unlike SQ/RQ, for CQ doorbell, It seems that we need some more works to protect it. We have started analyzing the details. Thanks, Cheng Xu