Page MenuHomePhabricator

PS relies on linking ITS library to get its definition
Open, NormalPublic


Although ITS & PS are known to be tightly-coupled, the current code seems to be more than that.
Current ITS/PS look more like conjoined twins, instead of working side-by-side and still being two identities.

One of the tricky stuff is that, PS_xxx is defined under ITS scope.
Which relies on linking ITS library to get its own definition from ITS.

ps_encrypted_object.c & PS_ENCRYPTION for example:
PS_ENCRYPTION is set to ON by default (config/config_default.cmake)
Source code, in ITS, will *see* the definition because of the $<$<BOOL:${PS_ENCRYPTION}>:PS_ENCRYPTION> statement in CMakeLists.txt

However, PS does not have the same definition in its CMakeLists.txt.
Theoretically, Source code under PS scope would have compiling error when it compiles ps_encrypted_object.c, because the code uses the field encapsulated by PS_ENCRYPTION, which is defined in ps_object_defs.h.
Magically, PS_ENCRYPTION is defined when it compiles ps_encrypted_object.c.

It's being used in both ITS & PS, and the tfm_ps_init() is almost identical to the code in the TFM_PARTITION_PROTECTED_STORAGE scope in tfm_its_init().

Event Timeline

AlamyLiu triaged this task as Normal priority.Thu, Apr 29, 7:10 AM
AlamyLiu created this task.
davidhuziji added a subscriber: davidhuziji.

Hi Alamy,

Thanks for your interest in PS/ITS services.

Yes, the PS and ITS service are highly coupled. But not mutually coupled. That means the PS service relies on ITS service. But in turn, ITS service does not rely on PS service. The main reason for PS calling the ITS partition is to reduce code size. It means only one copy of the filesystem/flash code is needed in the ITS partition, with PS able to use it too by calling ITS.

The build time configurations related to the flash operations are passed into the ITS partition as PS operates the flash via ITS.

The file ps_encrypted_object.c is only compiled into the ps partition when PS_ENCRYPTION is ON. See