drivers/ufs/core/ufshcd.c | 9 +++++++++ 1 file changed, 9 insertions(+)
Older UFS spec devices (2.2 and earlier) do not expose per-region RPMB
sizes, as only one RPMB region is supported. In such cases, the size of
the single RPMB region can be deduced from the Logical Block Count and
Logical Block Size fields in the RPMB Unit Descriptor.
Add a fallback mechanism to calculate the RPMB region size from these
fields if the device implements an older spec, so that the RPMB driver
can work with such devices - otherwise it silently skips the whole RPMB.
Section 14.1.4.6 (RPMB Unit Descriptor)
Link: https://www.jedec.org/system/files/docs/JESD220C-2_2.pdf
Cc: stable@vger.kernel.org
Fixes: b06b8c421485 ("scsi: ufs: core: Add OP-TEE based RPMB driver for UFS devices")
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/ufs/core/ufshcd.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 52ffd0c3aa4c..80be7d0a0315 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -5249,6 +5249,15 @@ static void ufshcd_lu_init(struct ufs_hba *hba, struct scsi_device *sdev)
hba->dev_info.rpmb_region_size[1] = desc_buf[RPMB_UNIT_DESC_PARAM_REGION1_SIZE];
hba->dev_info.rpmb_region_size[2] = desc_buf[RPMB_UNIT_DESC_PARAM_REGION2_SIZE];
hba->dev_info.rpmb_region_size[3] = desc_buf[RPMB_UNIT_DESC_PARAM_REGION3_SIZE];
+
+ if (hba->dev_info.wspecversion <= 0x0220) {
+ /* Only one RPMB region used, and no per-region size information */
+ hba->dev_info.rpmb_region_size[0] =
+ get_unaligned_be64(desc_buf
+ + RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_COUNT)
+ << desc_buf[RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_SIZE]
+ >> 17; /* convert to 128 kBytes units */
+ }
}
---
base-commit: 3f24e4edcd1b8981c6b448ea2680726dedd87279
change-id: 20260129-ufs-rpmb-d198a699a40d
Best regards,
--
Alexey Charkov <alchark@flipper.net>On Thu, 2026-01-29 at 11:38 +0400, Alexey Charkov wrote:
> + hba->dev_info.rpmb_region_size[0] =
> + get_unaligned_be64(desc_buf
> + +
> RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_COUNT)
> + <<
> desc_buf[RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_SIZE]
> + >> 17; /* convert to 128 kBytes units */
> + }
> }
Hi Alexey,
thanks for your fix, I didn't notice there is UFS 2.x on the market which will
use UFS OP-TEE RPMB framework.
here is potential u8 Overflow, since for the UFS3.x+, it is u8 in unit
descriptor, but
The calculation can overflow for larger RPMB regions (>32MB):
- A u8 can only represent up to 255 × 128KB = ~32MB
- The shift result is assigned directly without bounds checking
Kind regards,
Bean
On Thu, Jan 29, 2026 at 8:53 PM Bean Huo <huobean@gmail.com> wrote: > > On Thu, 2026-01-29 at 11:38 +0400, Alexey Charkov wrote: > > + hba->dev_info.rpmb_region_size[0] = > > + get_unaligned_be64(desc_buf > > + + > > RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_COUNT) > > + << > > desc_buf[RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_SIZE] > > + >> 17; /* convert to 128 kBytes units */ > > + } > > } > > Hi Alexey, > > thanks for your fix, I didn't notice there is UFS 2.x on the market which will > use UFS OP-TEE RPMB framework. Hi Bean, it turns out many of the UFS modules for Rockchip RK3576 based devices are 2.2. I'm poking around the OP-TEE support on that platform, and discovered that the existing driver didn't see the RPMB at all, spent quite a bit of time trying to figure it out before spotting the difference between the two spec versions :) > here is potential u8 Overflow, since for the UFS3.x+, it is u8 in unit > descriptor, but > > > The calculation can overflow for larger RPMB regions (>32MB): > - A u8 can only represent up to 255 × 128KB = ~32MB > - The shift result is assigned directly without bounds checking The spec says it can only be up to 16MB maximum (see section 12.4.3.1 RPMB Resources), so it should always fit. Happy to add a comment about that. Best regards, Alexey
On Thu, 2026-01-29 at 21:10 +0400, Alexey Charkov wrote: > On Thu, Jan 29, 2026 at 8:53 PM Bean Huo <huobean@gmail.com> wrote: > > > > On Thu, 2026-01-29 at 11:38 +0400, Alexey Charkov wrote: > > > + hba->dev_info.rpmb_region_size[0] = > > > + get_unaligned_be64(desc_buf > > > + + > > > RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_COUNT) > > > + << > > > desc_buf[RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_SIZE] > > > + >> 17; /* convert to 128 kBytes units */ > > > + } > > > } > > > > Hi Alexey, > > > > thanks for your fix, I didn't notice there is UFS 2.x on the market which > > will > > use UFS OP-TEE RPMB framework. > > Hi Bean, it turns out many of the UFS modules for Rockchip RK3576 > based devices are 2.2. I'm poking around the OP-TEE support on that > platform, and discovered that the existing driver didn't see the RPMB > at all, spent quite a bit of time trying to figure it out before > spotting the difference between the two spec versions :) > > > here is potential u8 Overflow, since for the UFS3.x+, it is u8 in unit > > descriptor, but > > > > > > The calculation can overflow for larger RPMB regions (>32MB): > > - A u8 can only represent up to 255 × 128KB = ~32MB > > - The shift result is assigned directly without bounds checking > > The spec says it can only be up to 16MB maximum (see section 12.4.3.1 > RPMB Resources), so it should always fit. Happy to add a comment about > that. > > Best regards, > Alexey Hi Alexey, Thanks for the clarification on the 16MB RPMB limit - that addresses the overflow concern. In your above operation, why not use SZ_128K to avoid the magic number? BTW, please update your comment. Kind regards, Bean
On Fri, Jan 30, 2026 at 2:26 PM Bean Huo <huobean@gmail.com> wrote: > > On Thu, 2026-01-29 at 21:10 +0400, Alexey Charkov wrote: > > On Thu, Jan 29, 2026 at 8:53 PM Bean Huo <huobean@gmail.com> wrote: > > > > > > On Thu, 2026-01-29 at 11:38 +0400, Alexey Charkov wrote: > > > > + hba->dev_info.rpmb_region_size[0] = > > > > + get_unaligned_be64(desc_buf > > > > + + > > > > RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_COUNT) > > > > + << > > > > desc_buf[RPMB_UNIT_DESC_PARAM_LOGICAL_BLK_SIZE] > > > > + >> 17; /* convert to 128 kBytes units */ > > > > + } > > > > } > > > > > > Hi Alexey, > > > > > > thanks for your fix, I didn't notice there is UFS 2.x on the market which > > > will > > > use UFS OP-TEE RPMB framework. > > > > Hi Bean, it turns out many of the UFS modules for Rockchip RK3576 > > based devices are 2.2. I'm poking around the OP-TEE support on that > > platform, and discovered that the existing driver didn't see the RPMB > > at all, spent quite a bit of time trying to figure it out before > > spotting the difference between the two spec versions :) > > > > > here is potential u8 Overflow, since for the UFS3.x+, it is u8 in unit > > > descriptor, but > > > > > > > > > The calculation can overflow for larger RPMB regions (>32MB): > > > - A u8 can only represent up to 255 × 128KB = ~32MB > > > - The shift result is assigned directly without bounds checking > > > > The spec says it can only be up to 16MB maximum (see section 12.4.3.1 > > RPMB Resources), so it should always fit. Happy to add a comment about > > that. > > > > Best regards, > > Alexey > > Hi Alexey, > > Thanks for the clarification on the 16MB RPMB limit - that addresses the > overflow concern. > > > In your above operation, why not use SZ_128K to avoid the magic number? > BTW, please update your comment. Good point, thanks Bean! Will amend in v2. Best regards, Alexey
On Fri, 2026-01-30 at 18:49 +0400, Alexey Charkov wrote: > > > The spec says it can only be up to 16MB maximum (see section 12.4.3.1 > > > RPMB Resources), so it should always fit. Happy to add a comment about > > > that. > > > > > > Best regards, > > > Alexey > > > > Hi Alexey, > > > > Thanks for the clarification on the 16MB RPMB limit - that addresses the > > overflow concern. > > > > > > In your above operation, why not use SZ_128K to avoid the magic number? > > BTW, please update your comment. > > Good point, thanks Bean! Will amend in v2. > > Best regards, > Alexey Alexey, did you send your new version patch? Kind regards, Bean
Hi Bean, On Wed, Feb 4, 2026 at 12:37 PM Bean Huo <huobean@gmail.com> wrote: > > On Fri, 2026-01-30 at 18:49 +0400, Alexey Charkov wrote: > > > > The spec says it can only be up to 16MB maximum (see section 12.4.3.1 > > > > RPMB Resources), so it should always fit. Happy to add a comment about > > > > that. > > > > > > > > Best regards, > > > > Alexey > > > > > > Hi Alexey, > > > > > > Thanks for the clarification on the 16MB RPMB limit - that addresses the > > > overflow concern. > > > > > > > > > In your above operation, why not use SZ_128K to avoid the magic number? > > > BTW, please update your comment. > > > > Good point, thanks Bean! Will amend in v2. > > > > Best regards, > > Alexey > > Alexey, > > did you send your new version patch? Just sent it out, thanks for your help! Best regards, Alexey
© 2016 - 2026 Red Hat, Inc.