Le 22 nov. 2017 10:35 PM, "Stuart Yoder" <stuart.yoder@arm.com> a écrit :

On 11/22/17 2:53 PM, Jerome Forissier wrote:

Hi Stuart,

Le 22 nov. 2017 9:28 PM, "Stuart Yoder" <stuart.yoder@arm.com <mailto:stuart.yoder@arm.com>> a écrit :

There is no storage controller driver in OP-TEE, as pointed out in the RPMB doc:

   There is no eMMC controller driver in OP-TEE. The device operations all have
   to go through the normal world. They are handled by the tee-supplicant process
   which further relies on the kernel's ioctl() interface to access the device.

Correct.

Is doing this a roadmap (or potential roadmap) item for OP-TEE?

I don't think it is at the moment.

I'm wondering
what discussions might have happened in the past, and if the idea has been
rejected for some reason. Or, is it a potential future to do item?

There are some technical challenges, but we have certainly not rejected the idea!

Anything you can share about what you see the challenges being?

Sure. The main difficulty I see is how to share device/controller between Normal and Secure World (configuration via DT, synchronisation). Indeed, for some platforms it might not be reasonable to consider that SW has exclusive access?

Then, there is the amount of code needed. Quite a lot AFAICT. Could we find some existing code with a BSD-compatible license?

Jerome

The use case would be if OP-TEE provided a secure key store, and access was
need to that key store prior to normal world being available...for example,
to store keys that encrypted the disk to be used by Linux.

Makes sense. That being said, there are probably simpler solutions to derive FDE keys (OTP/eFuse/crypto accelerator).

That was an example, and I can think of other cases where you may want secure storage,
but don't want to be dependent on Linux.

Thanks,
Stuart