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
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
op-tee@lists.trustedfirmware.org, jenswi@kernel.org,
sumit.garg@oss.qualcomm.com
Subject: Re: [PATCH v3 2/2] ufs: rpmb: use a fixed-length RPMB dev_id
Date: Wed, 26 Aug 2026 16:32:45 +0200 [thread overview]
Message-ID: <c041d409bf6f564c6743a0d03e0c851ce3afa6d5.camel@iokpp.de> (raw)
In-Reply-To: <20260821150612.3944782-3-jorge.ramirez@oss.qualcomm.com>
On Fri, 2026-08-21 at 17:06 +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, and it derives the key on that
> assumption.
>
> The UFS RPMB id built here is "<device_id>-R<region>", which is variable
> length and longer than 16 bytes. Passing it verbatim would tie the
> derived key to a length OP-TEE does not expect and diverge from the
> fixed-CID eMMC ABI, requiring OP-TEE to be taught about variable-length
> UFS ids.
>
> Hash the UFS id into a fixed 16-byte dev_id with blake2b instead. This
> keeps the derived key stable and unique per region while matching the
> eMMC CID layout OP-TEE relies on, so the key-derivation ABI stays
> identical and no OP-TEE change is needed. blake2b is used because it is
> already available in bootloaders such as U-Boot that must derive the
> same dev_id, avoiding the need to add a blake2s implementation there.
>
> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Looks good to me!
Reviewed-by: Bean Huo <beanhuo@micron.com>
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
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
op-tee@lists.trustedfirmware.org, jenswi@kernel.org,
sumit.garg@oss.qualcomm.com
Subject: Re: [PATCH v3 2/2] ufs: rpmb: use a fixed-length RPMB dev_id
Date: Wed, 26 Aug 2026 16:32:45 +0200 [thread overview]
Message-ID: <c041d409bf6f564c6743a0d03e0c851ce3afa6d5.camel@iokpp.de> (raw)
In-Reply-To: <20260821150612.3944782-3-jorge.ramirez@oss.qualcomm.com>
On Fri, 2026-08-21 at 17:06 +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, and it derives the key on that
> assumption.
>
> The UFS RPMB id built here is "<device_id>-R<region>", which is variable
> length and longer than 16 bytes. Passing it verbatim would tie the
> derived key to a length OP-TEE does not expect and diverge from the
> fixed-CID eMMC ABI, requiring OP-TEE to be taught about variable-length
> UFS ids.
>
> Hash the UFS id into a fixed 16-byte dev_id with blake2b instead. This
> keeps the derived key stable and unique per region while matching the
> eMMC CID layout OP-TEE relies on, so the key-derivation ABI stays
> identical and no OP-TEE change is needed. blake2b is used because it is
> already available in bootloaders such as U-Boot that must derive the
> same dev_id, avoiding the need to add a blake2s implementation there.
>
> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Looks good to me!
Reviewed-by: Bean Huo <beanhuo@micron.com>
next prev parent reply other threads:[~2026-08-26 14:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 15:06 [PATCH v3 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation Jorge Ramirez-Ortiz via OP-TEE
2026-08-21 15:06 ` Jorge Ramirez-Ortiz
2026-08-21 15:06 ` [PATCH v3 1/2] ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN Jorge Ramirez-Ortiz
2026-08-21 15:06 ` Jorge Ramirez-Ortiz via OP-TEE
2026-08-26 20:59 ` Bean Huo
2026-08-26 20:59 ` Bean Huo via OP-TEE
2026-08-21 15:06 ` [PATCH v3 2/2] ufs: rpmb: use a fixed-length RPMB dev_id Jorge Ramirez-Ortiz
2026-08-21 15:06 ` Jorge Ramirez-Ortiz via OP-TEE
2026-08-21 15:24 ` sashiko-bot
2026-08-26 6:38 ` Jorge Ramirez via OP-TEE
2026-08-26 6:38 ` Jorge Ramirez
2026-08-26 14:32 ` Bean Huo [this message]
2026-08-26 14:32 ` Bean Huo 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=c041d409bf6f564c6743a0d03e0c851ce3afa6d5.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.