CFG_RPMB_FS_DEV_ID and OP-TEE core awaraness about RPMB device id

[igoropaniuk]

Hi,

Is there any particular reason why OP-TEE core should be aware about RPMB dev id?
Why not to let OP-TEE linux driver/TEE supplicant make decisions about dev node to use for accessing
RPMB hw partition (for example, that information can be pulled from DT as an option)?

AFAIR 2-3 years ago we already discussed the issue with different probe order of mmc in U-Boot/Linux, when
eMMC has different ids in U-Boot/Linux (usually SD/eMMC are swapped), but don't re-call what decision (how to address that) we arrived at during that discussion.

Thanks!

[jenswi-linaro]

It's there for historical reasons. Keep in mind that it tee-supplicant need to know which RPMB device to use too.

[igoropaniuk]

@jenswi-linaro

I have some suggestions how it can be addressed from my POV, could you please provide your feedback:

1. The most trivial and non-intrusive workaround: add additional func handler to System PTA for changing RPMB dev id (and simple id getter()/setter() in tee_rpmb_fs.c + additional checks in tee_rpmb_read()/tee_rpmb_write() if the value was changed so we need to re-initialize RPMB FS).
   OP-TEE core will still be aware about that id, but at least we will be able to change it in runtime.
   Also no changes will be needed in tee supplicant.

2. We ignore dev id from RPC RPMB call handler in tee supplicant. Pretty straightforward solution for TEE supplicant implementation in U-Boot, however I'm not sure how we can provide that information to tee-supplicant daemon in REE, other than passing that as a command line argument.

3. We do the same as in 2, but we also completely carve out RPMB dev id from OP-TEE OS core. This leads to broken RPC API between core and tee-supplicant (so we won't be able to use old versions of OP-TEE OS with new optee_client and vice versa).

[jenswi-linaro]

Thanks for looking into this problem.

Of these I prefer option 2, with a twist. If information is found in DT (or possibly somewhere else in normal world) then the device id provided by OP-TEE is ignored. The linux tee-supplicant can perhaps look in /sys/firmware/devicetree.

[jforissier]

If information is found in DT (or possibly somewhere else in normal world) then the device id provided by OP-TEE is ignored.

That sounds good to me too. Normal world is free to use any means to find the proper device, the only thing that matters is that OP-TEE is always presented with the same device (and if not, OP-TEE will detect it thanks to the RPMB key).
DT is convenient but some people are reluctant to fill it with more than hardware description...

[etienne-lms]

If there's only one in the system, it's pretty obvious which to try.
So maybe let supplicant search for /dev/mmcblkXrpmb and pick it if found a single one, whatever ID?

If there are more, i agree it's not convenient to define REE emmc device ID value from secure world.

Will supplicant be allowed to read in /sys/firmware/devicetree in some SELinux like constrained contexts?

Maybe optee driver could have some DT property bindings for sharing ID between optee drv and optee core, in case of several emmc to distinguish.

[igoropaniuk]

Thanks @jenswi-linaro @jforissier @etienne-lms for your input

Maybe optee driver could have some DT property bindings for sharing ID between optee drv and optee core, in case of several emmc to distinguish.

I was about to suggest something like this:

firmware {                                                              
        optee {                                                         
                compatible = "linaro,optee-tz";                         
                method = "smc";
                rpmb-dev = <&mmc2>;                                         
        };                                                              
}; 

The linux tee-supplicant can perhaps look in /sys/firmware/devicetree.

The problem here is too find an association between a DT node and udev node in /dev (I'm not aware about any straightforward and standardized way to do that from userspace).

To do that we have to (for the example of rpmb-dev property listed above):

1. Get real DT node from alias reading from /proc/device-tree/aliases/mmc2 (/soc@0/bus@30800000/mmc@30b60000)
2. Check /dev/disk/by-path/platform-30b60000.mmc-rpmb using that mmc controller address.

Additional udev rules can also affect how the dev node will be named, so likely we can end up with empty /dev/disk/by-path
Although we can easily use that information from DT in U-Boot TEE supplicant, I would suggest for Linux env avoid any such type of tricks explained above. Maybe adding adding some udev rule that will create a symlink with a static name like /dev/teerpmb (frankly not sure if it's possible to do)

[igoropaniuk]

Just to make the story short having mmc2 alias in DT doesn't guarantee that mmc device will be probed as /dev/mmcblk2 in Linux.

[igoropaniuk]

RFC for U-Boot:
https://patchwork.ozlabs.org/project/uboot/list/?series=226084

[igoropaniuk]

RFC v2:
https://patchwork.ozlabs.org/project/uboot/list/?series=226085

[jenswi-linaro]

We need input from DT maintainer. If this approach isn't acceptable we'll need to find something else.

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.