[U-Boot] [PATCH 03/10] mmc: rpmb: add mmc_rpmb_route_frames()

[Jens Wiklander <jens.wiklander@linaro.org>]

Hi Igor,

On Thu, Aug 16, 2018 at 2:13 PM, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
> As I didn't have any available Hikey board, tested this on Poplar:
>
> Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org>
>
> BTW, we've had it up for discussion already, but just to clarify and summarize:
> As ID of eMMC is hardcoded in the OP-TEE OS core (CFG_RPMB_FS_DEV_ID),
> we will probably have issues on some platforms, where there is a
> difference in the probe order of MMC controllers (for example, on
> Poplar eMMC is 0 in U-boot, but in Linux it's 1, as SD is enumerated
> as 0).
> I guess it's unlikely that people will introduce changes to
> U-boot/Linux to make this order conform to each other, so instead, we
> should let the Normal World-part to decide what eMMC id to use from
> these RPMB frames.

Both U-boot and Linux are part of Normal World. I guess you're
suggesting to move the logic of selecting RPMB device based on the ID
from Secure World to tee-supplicant. For Linux that's a user space
daemon and in U-boot that's part of the OP-TEE driver. I think it
would be unfortunate to have this logic in user space, upgrades can
make a mess of this.

This is in one aspect a board specific problem which can be addressed
by defining the sequence number (what's indicated by
CFG_RPMB_FS_DEV_ID above) of relevant RPMB partitions on a specific
board. This is what we have been relying on indirectly so far.

Another way to deal with this problem is to let Secure World probe all
available RPMB partitions and use the one using the expected shared
secret for MACing. A drawback is that it's more complicated in Secure
World and will take a while before it's implemented.

Thanks,
Jens