Connecting RPMB to the storage APIs about optee_os HOT 5 CLOSED

Hi @youssefesmat , thanks for your proposal, please let us have some time to digest and discuss your suggestions. We will come back with an answer soon again.

from optee_os.

Hi @youssefesmat ,

Sorry for taking some time to get back to you, but now we have been looking at
your proposal and in general we like your suggestions. However, there are a few
things we would like to raise.

1. Connecting the APIs
   tee_file_operations
   We would prefer to not have platform specific tee_file_operations's. I.e,
   instead try to have only one for each type in generic code, i.e, flash based
   and the RPMB-based. We could add platform specific hooks if we find out that
   a certain platform has special needs.

   To start with, we would like to switch between the two using a compile time
   flag. Later on we most likely would like to make it possible to mix between
   both of them. For example, it could be useful to leverage RPMB for rollback
   counters while still having the possibility use flash for bulk storage. But
   as first patchset we would prefer either or.

2. RPMB APIs
   We're OK with your suggestions here.

3. Optimizations
   If implemented like a write-through cache, we're OK with this.

4. Open Questions
   Q: Is there a current ETA for pull request 231 such that we can take a
   dependency on it?
   A: Yes, the due date for that particular work is end of June. So that must be
   taken into account. Also, we see that it is critical that we make use of
   "encfs" also when communicating with RPMB, since the communication goes
   via the REE (basically the AES-GCM is important).

   Q: How is locking handled to the lower level RPCs? In other words can two
   threads attempt to write to the RPMB block at the same time?
   A: No, they will be blocked in the Linux kernel driver. See this section in the kernel driver.

from optee_os.

Thank you very much @jbech-linaro for looking at this. I will apply your feedback.

from optee_os.

Hi @youssefesmat ,

So, finally we have a plan from Linaro and it is as follows:

1. We will take the fork you created and rebase it on top of our master branch. In the first shot we will just use a flag to switch between tee_fs_common.c and tee_rpmb_fs_common.c (actually things might change here slightly).
2. We will implemented the missing pieces in tee-supplicant. Basically accepting messages and and call eMMC controller using the ioctl to Linux kernel.
3. Eventually implement some kind of simple RPMB emulator used by tee-supplicant that will make further development and verification a bit easier than having to solely to rely on real hardware.

After that we will probably look into the optimizations. As you've already indicated, the FAT look-a-like file system might not be the most efficient way of handling the data.

I would like to close this particular "issue" now, since the work actually is ongoing as we're speaking and related to this I would believe that we should close #323, since those patches is more or less the same kind of code as we can find in the fork you gave us (which is what we're trying to rebase and use)? Right? Please let me know if you're OK with my proposal?

from optee_os.

I will close this issue based on @jbech-linaro previous comment, please feel free to re-open if you have additional comments and questions about this topic.

from optee_os.