Searched hist:"63740 eac52a51b363e0b773800cc4beb490b9277" (Results 1 – 1 of 1) sorted by relevance
| /optee_os/core/tee/ |
| H A D | fs_dirfile.c | 63740eac52a51b363e0b773800cc4beb490b9277 Tue Feb 22 16:00:19 UTC 2022 Jerome Forissier <jerome@forissier.org> core: FS: make dirfile interface accept empty object ID
The TEE Internal Core API specification (v1.3.1) explicitly allows the
use of an empty object ID in TEE_RenamePersistentObject(). The text is:
newObjectID, newObjectIDLen: A buffer containing the new object
identifier. The identifier contains arbitrary bytes, including the
zero byte. The identifier length SHALL be less than or equal to
TEE_OBJECT_ID_MAX_LEN and can be zero.
(note the mention: "and can be zero").
Consequently, the OP-TEE filesystem code needs to accept an empty buffer
as a valid object identifier.
The REE FS implementation is not currently compatible with this because
a null struct dirfile_entry::oidlen is considered unused (free). In
order to differentiate between a free entry and one that represents an
object with an empty name, this commit adds a condition on the first
byte of struct dirfile_entry::oid. When zero, the structure is free;
when non-zero, it is the empty object ID. A new helper function is
introduced (is_free()) and used instead of simple tests on !oidlen.
The tee_fs_dirfile_find() function is modified to be able to match the
empty object ID. It used to interpret oidlen == 0 as a request to find a
free entry; this logic is moved to an new function: tee_fs_dirfile_new().
The RPMB implementation (core/tee/tee_rpmb_fs.c) has no problem because
it stores absolute object names including the TA UUID in a FAT structure
like so: "/<TA UUID>/<Object ID in hexadecimal>". An empty object ID is
therefore not a corner case.
Link: https://github.com/OP-TEE/optee_os/issues/5171
Reported-by: Sadiq Hussain <sadiq.muchumarri@intel.com>
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
|