tee-supplicant can be configured at build-time to either use a real RPMB
or to emulate one. The default is to emulate one, and that appears
to be what the Debian binary does today. Please provide support for using
a real RPMB.

We've been discussing this with upstream at
https://github.com/OP-TEE/optee_client/pull/355 , which is an attempt
to make emulation a runtime option. An argument is being made that
it should remain a build time switch, to avoid having to ship the
emulation code in production environments. We'll see how that shakes
out.

If this remains a build-time switch, one option would be for Debian to
consider building 2 different binary packages. Would the maintainer be
open to that?

Hi Dann,

Yeah. If that's the only option to make it work. But it seems to me that the package will be very ugly. Maybe we can wait until Debian Trixie has a more clear release date (release plan) and then decide it.

Currently I still think that it is possible to upstream the patch. Another option is to apply the patch locally in Debian. But it is scary either because we have to rebase it everytime.

Yours,
Paul

於 2023年9月15日 下午7:10:38 [GMT+05:30]，dann frazier <dannf@dannf.org> 寫到：

Dear maintainer,

the tee-supplicant binary in trixie is built with the upstream default
RPMB_EMU=1 (see tee-supplicant/CMakeLists.txt / Makefile in the
optee_client source; debian/rules does not override it). With RPMB_EMU,
the code accessing real RPMB devices (/dev/mmcblk*rpmb via
MMC_IOC_MULTI_CMD) is compiled out entirely and replaced with an
in-memory emulation.

Consequences on systems where OP-TEE uses RPMB-backed secure storage
(the standard configuration on devices with eMMC, e.g. any board
following the OP-TEE + fTPM measured-boot setup): the emulated RPMB
does not match the device's provisioned RPMB authentication key, all
secure storage operations fail (or, worse, appear to work against a
volatile fake), and TEE applications such as the Microsoft fTPM cannot
open sessions. Verification: `strings /usr/sbin/tee-supplicant | grep
mmcblk` returns nothing on the emu build.

RPMB emulation is an upstream development convenience for systems
without RPMB hardware; a distribution binary should serve real
hardware. Please build with RPMB_EMU disabled (-DRPMB_EMU=OFF for
cmake, RPMB_EMU=0 for make).

If there is concern about developers relying on the emulation, an
alternative is shipping both binaries or a runtime option, but the
default should be real RPMB access.

Thanks!