Hi Rasmus, Thank you for the patch.
On Thu, Sep 03, 2026 at 23:22, Rasmus Villemoes <[email protected]> wrote: > It is implied by the comments in avb_ops.h and the translation of > TEE_ERROR_STORAGE_NO_SPACE to AVB_IO_RESULT_ERROR_INSUFFICIENT_SPACE > done in common/avb_verify.c:invoke_func() that the > TA_AVB_CMD_READ_PERSIST_VALUE could return TEE_ERROR_STORAGE_NO_SPACE > when the value is longer than the passed buffer size, and that > param[1].u.memref.size would be set to the actual size, so that one > can allocate an appropriate buffer and re-read. > > However, that has AFAICT never been the case; there is no mention of > TEE_ERROR_STORAGE_NO_SPACE in the history of ta/avb/ in > https://github.com/OP-TEE/optee_os.git, and what the code does instead > is to return a value truncated to the given buffer size. In other > words, not only can one not determine the correct buffer size to > allocate, one is not even told that truncation happened. > > Changing the ABI of the existing TA_AVB_CMD_READ_PERSIST_VALUE method > to return an error in the case of a too small buffer was > rejected. Instead, a new TA_AVB_CMD_READ_PERSIST_VALUE2 method is > implemented which does return an error in case of a too small buffer > <https://github.com/OP-TEE/optee_os/pull/7959>. > > Make use of that method, thus making the <bytes> argument to > read_pvalue redundant - continue to accept it, but only use it as a > hint for the initial size, defaulting to 64. > > This obviously requires running against an updated op-tee, but as the > optee_rpmb command so far has not been usable programmatically (the > values read are only printed to the console), no existing boot logic > can have been relying on this command. > > Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]>
