linux-kernel - RE: [PATCH v2 6/6] ufs: core: Add advanced RPMB support in ufs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM6PR04MB6575B8A3BD70EAB5DC409EC3FC139@DM6PR04MB6575.namprd04.prod.outlook.com>
Date:   Mon, 28 Nov 2022 20:07:18 +0000
From:   Avri Altman <Avri.Altman@....com>
To:     Bean Huo <beanhuo@...pp.de>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "stanley.chu@...iatek.com" <stanley.chu@...iatek.com>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "bvanassche@....org" <bvanassche@....org>,
        "tomas.winkler@...el.com" <tomas.winkler@...el.com>,
        "daejun7.park@...sung.com" <daejun7.park@...sung.com>,
        "quic_cang@...cinc.com" <quic_cang@...cinc.com>,
        "quic_nguyenb@...cinc.com" <quic_nguyenb@...cinc.com>,
        "quic_xiaosenh@...cinc.com" <quic_xiaosenh@...cinc.com>,
        "quic_richardp@...cinc.com" <quic_richardp@...cinc.com>,
        "quic_asutoshd@...cinc.com" <quic_asutoshd@...cinc.com>,
        "hare@...e.de" <hare@...e.de>
CC:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 6/6] ufs: core: Add advanced RPMB support in ufs_bsg

> 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.
Fair enough.
Please add my reviewed-by tag to this patch as well.

Thanks,
Avri
> 
> 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