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.
Is doing this a roadmap (or potential roadmap) item for OP-TEE? 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?
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.
Thanks, Stuart
Hi Stuart,
Le 22 nov. 2017 9:28 PM, "Stuart Yoder" 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!
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).
Regards,
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?
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
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 theRPMB doc:
There is no eMMC controller driver in OP-TEE. The deviceoperations 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 hasbeen 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?
Stuart,
On 22 November 2017 at 21:53, Jerome Forissier jerome.forissier@linaro.org wrote:
Hi Stuart,
Le 22 nov. 2017 9:28 PM, "Stuart Yoder" stuart.yoder@arm.com a écrit :
Is doing this a roadmap (or potential roadmap) item for OP-TEE?
I don't think it is at the moment.
We're touching it from another angle, since we have started working with Android Verified Boot 2.0, which means that we will need to access RPMB before Linux kernel is up and running to be able to work with the rollback index in AVB2.0. It's still an open question whether we shall try to use the RPMB support in U-Boot or if it will be something done in OP-TEE directly.
Regards, Joakim
Joakim,
Just my $.02 on this one : isn’t the point of TEEs to reduce the amount of code that they run, so that better trust can be put into it, and a comprehensive code review remains possible.
Adding a full eMMC stack would mean a lot of code and a greater attack surface, wouldn’t it ? I fear that at one point we need to to consider implementing yet another trust level (we’d have to call them HTTs, Highly Trusted TEEs) because the amount of code in TEE has grown beyond control.
One the other hand, given such problem as early security verifications during boot, we currently are left with a mix of ARM Trusted Firmware and proprietary code, which isn’t an ideal situation.
Erwan
From: Tee-dev [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Joakim Bech Sent: jeudi 23 novembre 2017 08:32 To: Stuart Yoder Cc: tee-dev Subject: Re: [Tee-dev] eMMC driver in OP-TEE?
Stuart,
On 22 November 2017 at 21:53, Jerome Forissier <jerome.forissier@linaro.orgmailto:jerome.forissier@linaro.org> wrote: Hi Stuart,
Le 22 nov. 2017 9:28 PM, "Stuart Yoder" <stuart.yoder@arm.commailto:stuart.yoder@arm.com> a écrit :
Is doing this a roadmap (or potential roadmap) item for OP-TEE?
I don't think it is at the moment. We're touching it from another angle, since we have started working with Android Verified Boot 2.0, which means that we will need to access RPMB before Linux kernel is up and running to be able to work with the rollback index in AVB2.0. It's still an open question whether we shall try to use the RPMB support in U-Boot or if it will be something done in OP-TEE directly.
Regards, Joakim
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Hi Erwan,
On Fri, Nov 24, 2017 at 03:33:36PM +0000, erwan.louet@orange.com wrote:
Joakim,
Just my $.02 on this one : isn’t the point of TEEs to reduce the amount of code that they run, so that better trust can be put into it, and a comprehensive code review remains possible.
Yes, you are absolutely right here, we always needs to be aware of the "functional creep", otherwise we end up in the same situation with a big TEE kernel sooner or later.
Adding a full eMMC stack would mean a lot of code and a greater attack surface, wouldn’t it ? I fear that at one point we need to to consider implementing yet another trust level (we’d have to call them HTTs, Highly Trusted TEEs) because the amount of code in TEE has grown beyond control.
Exactly.
One the other hand, given such problem as early security verifications during boot, we currently are left with a mix of ARM Trusted Firmware and proprietary code, which isn’t an ideal situation.
As mentioned, we haven't decided anything here yet, we have just started working with Android Verified Boot 2.0 and it'll take a bit more time until we will start digging into the parts touching the TEE.
Summary, your point is absolutely valid and is something that must be considered.
-
erwan.louet＠orange.com -
Jerome Forissier -
Joakim Bech -
Stuart Yoder