Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <12c9e417168cdc044b9fd53c30d02ccab29179b2.camel@iokpp.de>
Subject: Re: [PATCH v2 6/6] ufs: core: Add advanced RPMB support in ufs_bsg
From:   Bean Huo <beanhuo@iokpp.de>
To:     Avri Altman <Avri.Altman@wdc.com>,
        "alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
        "beanhuo@micron.com" <beanhuo@micron.com>,
        "bvanassche@acm.org" <bvanassche@acm.org>,
        "tomas.winkler@intel.com" <tomas.winkler@intel.com>,
        "daejun7.park@samsung.com" <daejun7.park@samsung.com>,
        "quic_cang@quicinc.com" <quic_cang@quicinc.com>,
        "quic_nguyenb@quicinc.com" <quic_nguyenb@quicinc.com>,
        "quic_xiaosenh@quicinc.com" <quic_xiaosenh@quicinc.com>,
        "quic_richardp@quicinc.com" <quic_richardp@quicinc.com>,
        "quic_asutoshd@quicinc.com" <quic_asutoshd@quicinc.com>,
        "hare@suse.de" <hare@suse.de>
Cc:     "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Date:   Mon, 28 Nov 2022 20:01:27 +0100
In-Reply-To: <DM6PR04MB6575750D9C6F84FC3BE06AFBFC0D9@DM6PR04MB6575.namprd04.prod.outlook.com>
References: <20221120222217.108492-1-beanhuo@iokpp.de>
         <20221120222217.108492-7-beanhuo@iokpp.de>
         <DM6PR04MB6575750D9C6F84FC3BE06AFBFC0D9@DM6PR04MB6575.namprd04.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5-0ubuntu1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Tue, 2022-11-22 at 11:55 +0000, Avri Altman wrote:
> > +static int ufs_bsg_exec_advanced_rpmb_req(struct ufs_hba *hba,
> > struct
> > +bsg_job *job) {
> > +       struct ufs_rpmb_request *rpmb_request = job->request;
> > +       struct ufs_rpmb_reply *rpmb_reply = job->reply;
> > +       struct bsg_buffer *payload = NULL;
> > +       enum dma_data_direction dir;
> > +       struct scatterlist *sg_list;
> > +       int rpmb_req_type;
> > +       int sg_cnt;
> > +       int ret;
> > +       int data_len;
> > +
> > +       if (hba->ufs_version < ufshci_version(4, 0) || !hba-
> > > dev_info.b_advanced_rpmb_en ||
> > +           !(hba->capabilities & MASK_EHSLUTRD_SUPPORTED))
> > +               return -EINVAL;
> > +
> > +       if (rpmb_request->ehs_req.length != 2 || rpmb_request-
> > > ehs_req.ehs_type != 1)
> > +               return -EINVAL;
> Maybe you could also check:
> In case of rpmb write, the request payload 4096 × Advanced RPMB Block
> Count,
> And same goes for response payload for rpmb read.
> 
> Thanks,
> Avri
> 

Hi Avri, 

in Spec:

"If the Block Count indicates a value greater than bRPMB_ReadWriteSize,
then the authenticated data write/read operation fails and the Result
is set to “General failure” (0001h)."


I think this should be checked in the application in userspace because
if the application passes a wrong/incorrect payload length, it will
error out and have no effect on UFS. In order to add this check in a
driver in the kernel, we need to maintain bRPMB_ReadWriteSize in kernel
space. Sometimes this is a waste of resources because we don't know if
the client will access the RPMB.

I have enabled Advanced RPMB feature in the ufs-utils as an example,
will be refered in cover-letter in the next version.

Kind regards,
Bean