Difference between revisions of "XSMAsDefault TODO List"
From Xen
Lars.kurth (talk | contribs) (Created page with "== What do we want to achieve == == Known Issues == == TODO List == Category:Security") |
(→TODO List) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== What do we want to achieve == |
== What do we want to achieve == |
||
+ | |||
+ | XSM with default policy will have: |
||
+ | * Same functionality exposed to guests without regressions |
||
+ | * Have at minimum the same security as we have without XSM enabled. |
||
+ | * Have set of policies for device driver domains vs control domains. |
||
== Known Issues == |
== Known Issues == |
||
+ | |||
+ | * Cannot re-apply a new policy after guests have been running. |
||
== TODO List == |
== TODO List == |
||
[[Category:Security]] |
[[Category:Security]] |
||
+ | |||
+ | * Could initial build of Xen hypervisor include a built-in (inside .init.data) policy file? |
||
+ | * Can we make policies modularized? A core (perhaps built-in?) with amendments loaded later? |
Latest revision as of 18:30, 25 April 2016
What do we want to achieve
XSM with default policy will have:
- Same functionality exposed to guests without regressions
- Have at minimum the same security as we have without XSM enabled.
- Have set of policies for device driver domains vs control domains.
Known Issues
- Cannot re-apply a new policy after guests have been running.
TODO List
- Could initial build of Xen hypervisor include a built-in (inside .init.data) policy file?
- Can we make policies modularized? A core (perhaps built-in?) with amendments loaded later?