Thanks for the Miklos. Comments inline. I will spend next couple of weeks in analyzing this.

Regards

Manoj

-----Original Message----- From: Miklos Balint [mailto:Miklos.Balint@arm.com] Sent: Friday, August 2, 2019 6:26 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,

Apologies for the delayed response but I've been busy with time-critical assignments. I will list a couple of aspects that need to be analysed, but as you will see the design needs to be broken down to the very fundamental scenarios as the hardware and firmware states, related security implications need to be checked for each scenario:

Privilege: What level of isolation are you expecting to run? In level 1, there's no privilege control on the secure side, so that's relatively straightforward in this respect, however related security guarantees are lower as well. If, however, your deployment is level 2 or 3, it can get troublesome as if a secure partition is pre-empted by a non-secure interrupt, a subsequent veneer call - if in thread mode - would either be running privileged or non-privileged depending of what had been pre-empted, at which point your driver will potentially lack the privilege needed to perform its functionality, therefore you need to trap that call so SPM can make required adjustments.

@Manoj:what do you mean by " you need to trap that call so SPM can make required adjustments"

Stacks: If your driver is called from ns handler mode, the veneer and rest of the driver will execute in handler mode using secure MSP (using the stack frame of the SPM), while if the call itself is thread mode, the veneer would use the secure PSP. This latter case gets tricky if you expect to make concurrent requests, support pre-emption, as without the SPM you would be executing on an unknown stack frame. Either way, you need to account for the stack usage of the driver when allocating stacks of different entities it may have pre-empted.

@Manoj: agree with this.

Mode: Whether handler or thread mode transition is expected between NS-S is an important question as the source mode when a secure veneer call is made has direct impact on the secure execution. @Manoj: I expect the calls to be made in the Thread mode from non-secure side. (how is secure execution affected in this case)

Execution model: Are you allowing pre-emption of secure execution or are non-secure interrupts deprioritised? Would your drivers be preemptible, are interrupts expected to be nested? Is an NS RTOS used or is the application bare-metal? The topics above have quite different resolutions depending on the execution model of your system.

@Manoj: yes there may be pre-emption of secure execution. At this point I haven’t decided on preemption in drivers but most functions in the driver works with some global data structures and that manipulation code has to be in critical section, I don’t expect interrupts to be nested, Yes the NS RTOS is used.

NS call-back: This is indeed a feature we're investigating for TF-M but so far we've only considered scenarios relating to cooperation between the non-secure RTOS and SPM, not for applications. The issue there is that one has to have a registration of the call-back function, or a platform-specific hardware signalling mechanism, for secure code to get the information needed to make a call. Even then, NS RTOS and the secure entity making the call need to have agreement on what the active non-secure context is.

--------

These are the initial aspects and implications I can see. As you can see a critical aspect is the full list of hardware and software states at the time of the trigger action, and at the time of transition from NS to S domain. Each of these aspects need to be investigated for your use cases to make sure that both the NS RTOS and SPM would be in a consistent state - both internally, and with respect to their shared states, e.g. active NS context - when the driver completes execution. Additionally, the secure driver needs to deal with input sanitization, access control and all other aspects of security while bypassing SPM.

I know this is still very generic, but I hope it helps to some extent in scoping the investigation into your usage model.

Please also note that there are plans for making a more detailed analysis of how to reduce the role of SPM in the simplest of use cases - taking the most restrictive approach in all aspects listed above -, so that might yield some useful outcome - depending on how good a fit that is with your design -, but I'm not sure about where that will fit into the rather crammed roadmap we're working with. I don't know if you'd be interested in drafting an analysis to seed and accelerate that activity?

@Manoj: Definitely this needs an analysis to seed and accelerate this activity.

Regards Miklos

-----Original Message----- From: R, Manoj manojr@ti.com Sent: 01 August 2019 16:11 To: Miklos Balint Miklos.Balint@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: [TF-M] independent device driver model working along side SPM

Hi,

Waiting for response this query.

Regards

Manoj

-----Original Message----- From: R, Manoj Sent: Thursday, July 11, 2019 9:49 PM To: 'Miklos Balint'; 'tf-m@lists.trustedfirmware.org' Cc: 'nd' Subject: RE: [TF-M] independent device driver model working along side SPM

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