Miklos,
Further is there a model wherein we can split the implementation across secure partition (where in some of the API are operating in secure container) and probably couple of latency sensitive API are working alongside SPM using plain veneers. What will be the implications of such a model (assuming that data structures are shared). What are the careabouts we should consider in that case.
Regards
Manoj
-----Original Message----- From: R, Manoj Sent: Thursday, July 11, 2019 3:38 PM To: 'Miklos Balint'; tf-m@lists.trustedfirmware.org Cc: nd Subject: RE: [TF-M] independent device driver model working along side SPM
Thanks for the reply Miklos.
At present we are evaluating the benchmark numbers for using secure partitions for implementing (library model) the driver. This device driver is in charge of communicating to another core to get necessary actions done and the core has lot of scope for parallelism. We can have another mpu kind of hardware which can work with defining permissions for the secure context id in which the driver will work in case we go ahead with driver working alongside TFM with veneers exposed in nsc. We want this driver to be just the one which posts jobs to other core and later the non-secure side shall be intimated about results using a secure callback to non-secure side. This callback feature is also something which is a miss in current TFM implementation as far as I know.
Regards
Manoj
-----Original Message----- From: Miklos Balint [mailto:Miklos.Balint@arm.com] Sent: Thursday, July 11, 2019 1:57 PM To: R, Manoj; tf-m@lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] RE: [TF-M] independent device driver model working along side SPM
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