Add support for policy modules #194
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This allows to remove the `#[cfg]` guards for the platforms and (in the future) for the policy modules. The problem with `#[cfg]` guards is that they don't scale well with the number of choices, and introduce bug-prone conditional compilation which we only really need for the architecture-dependant assembly. The new `select_env` proc macro takes the name of an environment variable, and then matches its value against a list of possible values. It then replaces the macro invocation with the patch of the matching arm.
This patch adds bare bone support for policy modules in Miralis. Policy modules are a new mechanism to define policies that should be enforced by Miralis. By default Miralis does not isolate the rest of the system from the virtualieed firmware, therefore does not provide any security guarantee on its own. As different systems requires different isolation policies (e.g. protect VMs or user-level enclaves) we add a new modular mechanism to defined policies within Miralis through Policy Modules. A policy module simply implements the trait and can be selected through our config mechanism. In multiple places of Miralis we will add hooks that can be leveraged by policy modules to interpose on some events, enabling the definition of custom policies. This patch introduces two policy modules: the default policy which provides no further isolation, and the Keystone policy which is currently a placeholder but will be used in the future to implement the Keystone ABI and policies. As of this commit it is possible to run a firmware with the Keystone policy using: ``` just run default config/qemu-keystone.toml ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch adds bare bone support for policy modules in Miralis. Policy
modules are a new mechanism to define policies that should be enforced
by Miralis. By default Miralis does not isolate the rest of the system
from the virtualieed firmware, therefore does not provide any security
guarantee on its own.
As different systems requires different isolation policies (e.g. protect
VMs or user-level enclaves) we add a new modular mechanism to defined
policies within Miralis through Policy Modules. A policy module simply
implements the trait and can be selected through our config mechanism.
In multiple places of Miralis we will add hooks that can be leveraged by
policy modules to interpose on some events, enabling the definition of
custom policies.
This patch introduces two policy modules: the default policy which
provides no further isolation, and the Keystone policy which is
currently a placeholder but will be used in the future to implement the
Keystone ABI and policies. As of this commit it is possible to run a
firmware with the Keystone policy using: