On Wed, Apr 06, 2022 at 11:16:10AM +0200, Jan Beulich wrote: > On 06.04.2022 11:09, Roger Pau Monné wrote: > > On Wed, Apr 06, 2022 at 10:48:23AM +0200, Jan Beulich wrote: > >> On 06.04.2022 10:46, Roger Pau Monné wrote: > >>> On Wed, Apr 06, 2022 at 09:06:59AM +0200, Jan Beulich wrote: > >>>> On 05.04.2022 19:17, Jason Andryuk wrote: > >>>>> On Mon, Apr 4, 2022 at 11:34 AM Daniel P. Smith > >>>>> <dpsm...@apertussolutions.com> wrote: > >>>>>> On 3/31/22 09:16, Jason Andryuk wrote: > >>>>>>> For the default policy, you could start by creating the system domains > >>>>>>> as privileged and just have a single hook to drop privs. Then you > >>>>>>> don't have to worry about the "elevate" hook existing. The patch 2 > >>>>>>> asserts could instead become the location of xsm_drop_privs calls to > >>>>>>> have a clear demarcation point. That expands the window with > >>>>>>> privileges though. It's a little simpler, but maybe you don't want > >>>>>>> that. However, it seems like you can only depriv once for the Flask > >>>>>>> case since you want it to be one-way. > >>>>>> > >>>>>> This does simplify the solution and since today we cannot differentiate > >>>>>> between hypervisor setup and hypervisor initiated domain construction > >>>>>> contexts, it does not run counter to what I have proposed. As for > >>>>>> flask, > >>>>>> again I do not believe codifying a domain transition bound to a new XSM > >>>>>> op is the appropriate approach. > >>>>> > >>>>> This hard coded domain transition does feel a little weird. But it > >>>>> seems like a natural consequence of trying to use Flask to > >>>>> deprivilege. I guess the transition could be behind a > >>>>> dom0less/hyperlaunch Kconfig option. I just don't see a way around it > >>>>> in some fashion with Flask enforcing. > >>>>> > >>>>> Another idea: Flask could start in permissive and only transition to > >>>>> enforcing at the deprivilege point. Kinda gross, but it works without > >>>>> needing a transition. > >>>> > >>>> I don't think that would be right. Logically such behavior ought to be > >>>> mirrored to SILO, and I'll take that for the example for being the > >>>> simpler model: Suppose an admin wants to disallow communication > >>>> between DomU-s created by Xen. Such would want enforcing when creating > >>>> those DomU-s, despite the creator (Xen) being all powerful. If the > >>>> device tree information said something different (e.g. directing for > >>>> an event channel to be established between two such DomU-s), this > >>>> should be flagged as an error, not be silently permitted. > >>> > >>> I could also see this argument the other way around: what if an admin > >>> wants to disallow domUs freely communicating between them, but would > >>> still like some controlled domU communication to be possible by > >>> setting up those channels at domain creation? > >> > >> Well, imo that would require a proper (Flask) policy then, not SILO mode. > > > > But when creating such domains in SILO mode from dom0, dom0 would be > > allowed to create and bind event channels to the created domains, even > > if the domain themselves are not allowed the operation. > > > > That's because the check in evtchn_bind_interdomain() is done against > > 'current' and not the domain where the event channel will be bound. > > Yes and no - the check is against current, but that's because > communication is established between current ( == ld) and rd. The > function in its present shape simply can't establish a channel > between two arbitrary domains.
I've got confused with evtchn_alloc_unbound() that does take a local and remote domains as parameters, but in that case the xsm check is done against ld (which might not be current) and rd. Thanks, Roger.
