From: Bean Huo <beanhuo@iokpp.de>
To: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>,
James.Bottomley@HansenPartnership.com,
martin.petersen@oracle.com, alim.akhtar@samsung.com,
avri.altman@wdc.com, bvanassche@acm.org, beanhuo@micron.com,
can.guo@oss.qualcomm.com, sumit.garg@oss.qualcomm.com,
jenswi@kernel.org
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
op-tee@lists.trustedfirmware.org
Subject: Re: [PATCH v4 2/2] ufs: rpmb: use a fixed-length RPMB dev_id
Date: Sun, 30 Aug 2026 18:05:42 +0200 [thread overview]
Message-ID: <0993b0a14b17331dff17dd643be56144d0ae267b.camel@iokpp.de> (raw)
In-Reply-To: <20260827070345.2853821-3-jorge.ramirez@oss.qualcomm.com>
On Thu, 2026-08-27 at 09:03 +0200, Jorge Ramirez-Ortiz wrote:
> The RPMB authentication key is derived from the dev_id handed to the
> RPMB subsystem. OP-TEE implements the eMMC RPMB flow, where the dev_id
> is the eMMC CID: a fixed 16-byte value the key derivation depends on.
>
> The UFS RPMB id is "<device_id>-R<region>", which is variable length
> and longer than 16 bytes. Handing it to the RPMB subsystem as-is would
> tie the derived key to a length OP-TEE does not expect and diverge from
> the fixed-CID eMMC ABI, forcing OP-TEE to be taught about
> variable-length UFS ids.
>
> A fixed 16-byte dev_id is needed so the derived key stays stable and
> unique per region while matching the eMMC CID layout OP-TEE relies on,
> keeping the key-derivation ABI identical with no OP-TEE change. The
> reduction to a fixed 16 bytes must also be reproducible by the
> bootloaders (such as U-Boot) that derive the same dev_id.
>
> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
I gave my Reviewed-by on v3 2/2 [1], but it seems to have been dropped here. If
the patch hasn't changed much, must be picked, add again:
Reviewed-by: Bean Huo <beanhuo@micron.com>
Documentation/process/submitting-patches.rst asks author to carry review tags
into later versions, and to note it below the '---' when a tag is dropped.
[1]https://lore.kernel.org/all/c041d409bf6f564c6743a0d03e0c851ce3afa6d5.camel@iokpp.de/
Kind regards,
Bean
WARNING: multiple messages have this Message-ID (diff)
From: Bean Huo via OP-TEE <op-tee@lists.trustedfirmware.org>
To: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>,
James.Bottomley@HansenPartnership.com,
martin.petersen@oracle.com, alim.akhtar@samsung.com,
avri.altman@wdc.com, bvanassche@acm.org, beanhuo@micron.com,
can.guo@oss.qualcomm.com, sumit.garg@oss.qualcomm.com,
jenswi@kernel.org
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
op-tee@lists.trustedfirmware.org
Subject: Re: [PATCH v4 2/2] ufs: rpmb: use a fixed-length RPMB dev_id
Date: Sun, 30 Aug 2026 18:05:42 +0200 [thread overview]
Message-ID: <0993b0a14b17331dff17dd643be56144d0ae267b.camel@iokpp.de> (raw)
In-Reply-To: <20260827070345.2853821-3-jorge.ramirez@oss.qualcomm.com>
On Thu, 2026-08-27 at 09:03 +0200, Jorge Ramirez-Ortiz wrote:
> The RPMB authentication key is derived from the dev_id handed to the
> RPMB subsystem. OP-TEE implements the eMMC RPMB flow, where the dev_id
> is the eMMC CID: a fixed 16-byte value the key derivation depends on.
>
> The UFS RPMB id is "<device_id>-R<region>", which is variable length
> and longer than 16 bytes. Handing it to the RPMB subsystem as-is would
> tie the derived key to a length OP-TEE does not expect and diverge from
> the fixed-CID eMMC ABI, forcing OP-TEE to be taught about
> variable-length UFS ids.
>
> A fixed 16-byte dev_id is needed so the derived key stays stable and
> unique per region while matching the eMMC CID layout OP-TEE relies on,
> keeping the key-derivation ABI identical with no OP-TEE change. The
> reduction to a fixed 16 bytes must also be reproducible by the
> bootloaders (such as U-Boot) that derive the same dev_id.
>
> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
I gave my Reviewed-by on v3 2/2 [1], but it seems to have been dropped here. If
the patch hasn't changed much, must be picked, add again:
Reviewed-by: Bean Huo <beanhuo@micron.com>
Documentation/process/submitting-patches.rst asks author to carry review tags
into later versions, and to note it below the '---' when a tag is dropped.
[1]https://lore.kernel.org/all/c041d409bf6f564c6743a0d03e0c851ce3afa6d5.camel@iokpp.de/
Kind regards,
Bean
next prev parent reply other threads:[~2026-08-30 16:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 7:03 [PATCH v4 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation Jorge Ramirez-Ortiz
2026-08-27 7:03 ` Jorge Ramirez-Ortiz via OP-TEE
2026-08-27 7:03 ` [PATCH v4 1/2] ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN Jorge Ramirez-Ortiz
2026-08-27 7:03 ` Jorge Ramirez-Ortiz via OP-TEE
2026-08-30 15:44 ` Bean Huo
2026-08-30 15:44 ` Bean Huo via OP-TEE
2026-08-31 8:25 ` Stanley Jhu via OP-TEE
2026-08-31 8:25 ` Stanley Jhu
2026-08-27 7:03 ` [PATCH v4 2/2] ufs: rpmb: use a fixed-length RPMB dev_id Jorge Ramirez-Ortiz
2026-08-27 7:03 ` Jorge Ramirez-Ortiz via OP-TEE
2026-08-27 7:17 ` sashiko-bot
2026-08-30 16:05 ` Bean Huo [this message]
2026-08-30 16:05 ` Bean Huo via OP-TEE
2026-08-31 8:25 ` Stanley Jhu
2026-08-31 8:25 ` Stanley Jhu via OP-TEE
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=0993b0a14b17331dff17dd643be56144d0ae267b.camel@iokpp.de \
--to=beanhuo@iokpp.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=can.guo@oss.qualcomm.com \
--cc=jenswi@kernel.org \
--cc=jorge.ramirez@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=op-tee@lists.trustedfirmware.org \
--cc=sumit.garg@oss.qualcomm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.