Hi Manoj,
Please elaborate on the problem you are seeing and the steps you want to take so we can consider if it's something TF-M is in the process of addressing or if it is out of scope. On first read I feel there's a contradiction: The point of having TF-M - or any secure "supervising entity" - in the system is that it has awareness of the goings-on in the system, understands the states of parallel contexts that are supported by the hardware, to control its security aspects. Having a device driver "not plugged in TF-M" would, on the face of it, defeat the purpose of TF-M as a management entity, and the device driver would need not only to handle its own threat vectors, but any potential collisions with TF-M's understanding and control of the system state, making it, in effect, part of the management entity. So rather than the driver being not plugged in, I guess what we need to work out is how TF-M can be extended to cover the type of use case you are working on, without compromising the holistic security model that TF-M implements - but there's no one-size-fits-all solution.
Thanks and regards Miklos
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of R, Manoj via TF-M Sent: 05 July 2019 10:24 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] independent device driver model working along side SPM
Hi,
Is there a design guideline available for device driver which is working on secure side alongside SPM. I do not want to plug my driver in TF-M due to latency considerations.
Basically my plan is to introduce non secure callable veneers for calling the interfaces of the driver which I am introducing.
Any thoughts on this will be helpful.
Regards
Manoj