| Message ID | 20220630022110.31555-1-dpsmith@apertussolutions.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Adds starting the idle domain privileged | expand |
On Wed, 29 Jun 2022, Daniel P. Smith wrote: > This series makes it so that the idle domain is started privileged under the > default policy, which the SILO policy inherits, and under the flask policy. It > then introduces a new one-way XSM hook, xsm_transition_running, that is hooked > by an XSM policy to transition the idle domain to its running privilege level. > > Patch 3 is an important one, as first it addresses the issue raised under an > RFC late last year by Jason Andryuk regarding the awkward entanglement of > flask_domain_alloc_security() and flask_domain_create(). Second, it helps > articulate why it is that the hypervisor should go through the access control > checks, even when it is doing the action itself. The issue at hand is not that > the hypervisor could be influenced to go around these check. The issue is these > checks provides a configurable way to express the execution flow that the > hypervisor should enforce. Specifically with this change, it is now possible > for an owner of a dom0less or hyperlaunch system to express a policy where the > hypervisor will enforce that no dom0 will be constructed, regardless of what > boot construction details were provided to it. Likewise, an owner that does not > want to see dom0less or hyperlaunch to be used can enforce that the hypervisor > will only construct a dom0 domain. This can all be accomplished without the > need to rebuild the hypervisor with these features enabled or disabled. It looks like this patch series is fully acked except: - in theory we need an ack from Daniel for flask - there is a very small change to sched that would need an ack from George/Dario I think we should commit the series in a couple of days unless someone spots an issue with it. Let me know if you have any concerns with this. The minimal request to improve the in-code comment by Jan could be done on commit. Note that committing this series would also have the benefit of unblocking the ARM gitlab-ci pipeline.
On 6/30/22 18:35, Stefano Stabellini wrote: > On Wed, 29 Jun 2022, Daniel P. Smith wrote: >> This series makes it so that the idle domain is started privileged under the >> default policy, which the SILO policy inherits, and under the flask policy. It >> then introduces a new one-way XSM hook, xsm_transition_running, that is hooked >> by an XSM policy to transition the idle domain to its running privilege level. >> >> Patch 3 is an important one, as first it addresses the issue raised under an >> RFC late last year by Jason Andryuk regarding the awkward entanglement of >> flask_domain_alloc_security() and flask_domain_create(). Second, it helps >> articulate why it is that the hypervisor should go through the access control >> checks, even when it is doing the action itself. The issue at hand is not that >> the hypervisor could be influenced to go around these check. The issue is these >> checks provides a configurable way to express the execution flow that the >> hypervisor should enforce. Specifically with this change, it is now possible >> for an owner of a dom0less or hyperlaunch system to express a policy where the >> hypervisor will enforce that no dom0 will be constructed, regardless of what >> boot construction details were provided to it. Likewise, an owner that does not >> want to see dom0less or hyperlaunch to be used can enforce that the hypervisor >> will only construct a dom0 domain. This can all be accomplished without the >> need to rebuild the hypervisor with these features enabled or disabled. > > > It looks like this patch series is fully acked except: > - in theory we need an ack from Daniel for flask > - there is a very small change to sched that would need an ack from > George/Dario > > > I think we should commit the series in a couple of days unless someone > spots an issue with it. Let me know if you have any concerns with this. > > The minimal request to improve the in-code comment by Jan could be done > on commit. I already have those changes ready to go. I was holding off with the hope that Jason might find some time to read the last patch. I can try pinging him directly tomorrow to see if he is even in town, as this is a big holiday weekend here in the states. > Note that committing this series would also have the benefit of > unblocking the ARM gitlab-ci pipeline. v/r, dps
On 01.07.2022 00:35, Stefano Stabellini wrote: > On Wed, 29 Jun 2022, Daniel P. Smith wrote: >> This series makes it so that the idle domain is started privileged under the >> default policy, which the SILO policy inherits, and under the flask policy. It >> then introduces a new one-way XSM hook, xsm_transition_running, that is hooked >> by an XSM policy to transition the idle domain to its running privilege level. >> >> Patch 3 is an important one, as first it addresses the issue raised under an >> RFC late last year by Jason Andryuk regarding the awkward entanglement of >> flask_domain_alloc_security() and flask_domain_create(). Second, it helps >> articulate why it is that the hypervisor should go through the access control >> checks, even when it is doing the action itself. The issue at hand is not that >> the hypervisor could be influenced to go around these check. The issue is these >> checks provides a configurable way to express the execution flow that the >> hypervisor should enforce. Specifically with this change, it is now possible >> for an owner of a dom0less or hyperlaunch system to express a policy where the >> hypervisor will enforce that no dom0 will be constructed, regardless of what >> boot construction details were provided to it. Likewise, an owner that does not >> want to see dom0less or hyperlaunch to be used can enforce that the hypervisor >> will only construct a dom0 domain. This can all be accomplished without the >> need to rebuild the hypervisor with these features enabled or disabled. > > > It looks like this patch series is fully acked except: > - in theory we need an ack from Daniel for flask > - there is a very small change to sched that would need an ack from > George/Dario I don't think I've seen any R-b for the last patch. Jan
On Fri, 1 Jul 2022, Jan Beulich wrote: > On 01.07.2022 00:35, Stefano Stabellini wrote: > > On Wed, 29 Jun 2022, Daniel P. Smith wrote: > >> This series makes it so that the idle domain is started privileged under the > >> default policy, which the SILO policy inherits, and under the flask policy. It > >> then introduces a new one-way XSM hook, xsm_transition_running, that is hooked > >> by an XSM policy to transition the idle domain to its running privilege level. > >> > >> Patch 3 is an important one, as first it addresses the issue raised under an > >> RFC late last year by Jason Andryuk regarding the awkward entanglement of > >> flask_domain_alloc_security() and flask_domain_create(). Second, it helps > >> articulate why it is that the hypervisor should go through the access control > >> checks, even when it is doing the action itself. The issue at hand is not that > >> the hypervisor could be influenced to go around these check. The issue is these > >> checks provides a configurable way to express the execution flow that the > >> hypervisor should enforce. Specifically with this change, it is now possible > >> for an owner of a dom0less or hyperlaunch system to express a policy where the > >> hypervisor will enforce that no dom0 will be constructed, regardless of what > >> boot construction details were provided to it. Likewise, an owner that does not > >> want to see dom0less or hyperlaunch to be used can enforce that the hypervisor > >> will only construct a dom0 domain. This can all be accomplished without the > >> need to rebuild the hypervisor with these features enabled or disabled. > > > > > > It looks like this patch series is fully acked except: > > - in theory we need an ack from Daniel for flask > > - there is a very small change to sched that would need an ack from > > George/Dario > > I don't think I've seen any R-b for the last patch. Good point. I hope you'll be happy to give your Reviewed-by or Acked-by to the next version with the minor comments fixed.