From: Avri Altman <Avri.Altman@wdc.com>
To: Bean Huo <beanhuo@iokpp.de>,
"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>
Subject: RE: [RFC PATCH v1 2/2] ufs: core: Add advanced RPMB support in ufs_bsg
Date: Tue, 8 Nov 2022 21:00:31 +0000 [thread overview]
Message-ID: <DM6PR04MB657570B147A1D3B6FE5F8797FC3F9@DM6PR04MB6575.namprd04.prod.outlook.com> (raw)
In-Reply-To: <fa3905bff8ba47b0ed45f9221dd1d033ca553179.camel@iokpp.de>
> Avri,
> thanks for your comments and review.
>
>
> On Tue, 2022-11-08 at 19:09 +0000, Avri Altman wrote:
> > > Add advanced RPMB support in ufs_bsg. For these reasons, we try to
> > > implement Advanced RPMB in ufs_bsg:
> > > 1. According to the UFS specification, only one RPMB operation can
> > > be performed at any time. We can ensure this by using reserved slot
> > > and its dev_cmd sync operation protection mechanism.
> >
> > Regardless of its technical convenience, this approach unfortunately
> > breaks the spec.
> >
> > The spec say (please note the line numbers):
> >
> > ".....
> >
> > 5197 12.4.5.1 Advanced RPMB Message
> >
> > 5198 An Advanced RPMB Message is composed of an Advanced RPMB
> Meta
> > Information and a MAC/KEY in
> >
> > 5199 the EHS field in *COMMAND UPIU* and *RESPONSE UPIU*. Advanced
> > RPMB Data is delivered through
> >
> > ....."
>
> > Moreover, in the examples that are provided, it is still expected to
> > be carried via SECURITY PROTOCOL IN and SECURITY PROTOCOL OUT,
> >
> > See e.g. Figure 12.15 — Authenticated Data Write Flow (in Advanced
> > RPMB Mode).
> >
> >
> not quite get what you meant here.
I meant that we should still build upius that contains security protocol commands.
> >
>
> >
> > Therefore, wrapping the rpmb packets in a query-request upiu and
> > query-response upiu is not allowed.
> >
> >
>
> no, I didn't wrap RPMB packet in query-request/response, it is inupiu_req
> and upiu_rsp, it is upiu command.
I was thinking you are using a query request upiu because you are using device management commands flow,
And specifically, I didn't see where you are setting ucd_req_ptr->sc.cdb,
Which should hold the security protocol cdb.
> Based on Bart's suggestion, we shouldn't
> change the current ufs_bsg structure. I think his concern is that if we change
> ufs_bsg structure, the user space tool also needs to change as well.
Adding command upiu support will not break any ufs-bsg tools, e.g. ufs-utils.
It would just add this capability.
Thanks,
Avri
>
> >
> > Still, I agree that the approach you suggested, namely to rely on the
> > ufs-bsg driver, is the cleanest way to handle the advance rpmb access.
> >
> > However, IMHO, you need to do it is by adding command UPIU to the
> > ufs-bsg driver.
> >
> >
>
> Yes, agree with you on this point. But we still need to use reserved slots for
> RPMB or command UPIU, we don't want to affect IO requests on the normal
> path.
>
> One problem is that we didn't split the dev_manage command and the
> RPMB command in their completion handlers. I would like to change
> dev_man to passthrough or something else, and then split dev_man and
> RPMB, otherwise, they would be mixed in one dev_man completion handler.
> No technical issues here, just want to make it more readable and
> maintainable.
>
>
>
> Kind regards,
> Bean
>
> >
> > Thanks,
> >
> > Avri
next prev parent reply other threads:[~2022-11-08 21:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 13:10 [RFC PATCH v1 0/2] UFS Advanced RPMB Bean Huo
2022-11-07 13:10 ` [RFC PATCH v1 1/2] ufs: core: Advanced RPMB detection Bean Huo
2022-11-08 13:40 ` Avri Altman
2022-11-08 16:50 ` Bean Huo
2022-11-08 21:41 ` Avri Altman
2022-11-07 13:10 ` [RFC PATCH v1 2/2] ufs: core: Add advanced RPMB support in ufs_bsg Bean Huo
2022-11-08 19:09 ` Avri Altman
2022-11-08 19:28 ` Bean Huo
2022-11-08 21:00 ` Avri Altman [this message]
2022-11-08 21:17 ` Avri Altman
2022-11-09 8:07 ` Avri Altman
2022-11-08 12:37 ` [RFC PATCH v1 0/2] UFS Advanced RPMB Avri Altman
2022-11-08 12:53 ` Bean Huo
2022-11-09 8:18 ` Avri Altman
2022-11-10 13:50 ` Bean Huo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM6PR04MB657570B147A1D3B6FE5F8797FC3F9@DM6PR04MB6575.namprd04.prod.outlook.com \
--to=avri.altman@wdc.com \
--cc=alim.akhtar@samsung.com \
--cc=beanhuo@iokpp.de \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=daejun7.park@samsung.com \
--cc=hare@suse.de \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=quic_asutoshd@quicinc.com \
--cc=quic_cang@quicinc.com \
--cc=quic_nguyenb@quicinc.com \
--cc=quic_richardp@quicinc.com \
--cc=quic_xiaosenh@quicinc.com \
--cc=stanley.chu@mediatek.com \
--cc=tomas.winkler@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®