Allow providers to be optional or conditional depending on platform feature availability

[paulhowardarm]

Summary

Currently, the Parsec service fails to start up if it cannot instantiate all of the providers specified in configuration. This behaviour is by design. This request is to create a new feature where the service can run with only a subset of the configured providers. This allows configurations to be more portable across different hardware environments.

Details

In version 0.6.0 of Parsec, the service was tolerant of failed provider instantiations. It would still start successfully as long as at least one provider could be instantiated at start-up time. Any failures were logged and handled. This behaviour could lead to situations where the service was running with a different configuration from what was intended. This was deemed a security problem, and addressed as #297

In version 0.7.0 of Parsec, the service only starts successfully if all configured providers can be instantiated.

There are some legitimate use cases for permitting the service to run with only a subset of the configured providers. For example, one might wish to specify both the TPM provider and the Mbed provider simultaneously, but to only use the TPM where it is available, and fall back on using Mbed (or another back-end) where the TPM is absent. This could be achieved with 0.6.0 but is not possible with 0.7.0 due to the stricter start-up process. No such fall-back mechanism is possible.

It is possible to re-introduce this fall-back mechanism, but it must be done with care and it must be made intentional. We want to minimise the risk that the service could end up running with an unintended configuration or behaviour.

To make this intentional and explicit, Parsec would need to recognise new settings in the configuration file - possibly this could be an optional boolean flag on each provider, defaulting to the strict behaviour of 0.7.0, but allowing the config author to mark one or more providers as optional. An "optional" provider is defined as one that will not block the start-up of the service if it cannot be instantiated.

A careful definition of "cannot be instantiated" is also needed, because it is important to be able to distinguish between an optional provider and a badly-configured one, or one that fails unexpectedly due to some platform or environment error.

It might be the case that not all providers can support the new flag. The Mbed provider probably shouldn't, because that would always be the foundational default case that should always start successfully.

Providers that support the new flag could possibly do so via a preflight check mechanism of some kind. Rather than attempt to start the provider and catch any errors, the provider could inspect the state of the system first. The TPM provider, for example, could check whether the configured TCTI channel is present on the system.

The PKCS11 provider could possibly check for the presence of the PKCS11 library on disk.

Neither of these preflight checks are bulletproof, because it is conceivable that there is a misconfiguration in either TCTI settings or the PKCS11 library path. But such checks might be good enough.

It remains the case that providers should be specified in preferential order in the configuration. By the time the service is running, Parsec's default provider (for self-configuring clients) will be whichever was the first to be successfully instantiated.

Definition of Done

Having agreed and implemented the overall mechanism, it should at least be possible to create a Parsec configuration file that specifies both TPM (with device TCTI) and Mbed providers, and demonstrate that the TPM provider runs on the TPM-enabled platform, but only the Mbed provider runs on non-TPM platforms. This would restore the specific use case that was identified, which was possible (albeit via risky/buggy behaviour) in 0.6.0.

[paulhowardarm]

Just a thought, if we introduce a new config flag then it probably shouldn't be called optional (or required), because that's very vague and also conflicts horribly with the fact that individual config items can themselves be optional or required, so could get very messy. It probably should be something more verbose, specific and self-documenting. A possibility might be conditional_on_platform_support (defaulting to false).