On 3/30/22 11:15, Jason Andryuk wrote: > On Wed, Mar 30, 2022 at 10:04 AM Daniel P. Smith > <dpsm...@apertussolutions.com> wrote: >> >> On 3/30/22 08:30, Jason Andryuk wrote: >>> On Wed, Mar 30, 2022 at 2:30 AM Jan Beulich <jbeul...@suse.com> wrote: >>>> >>>> On 29.03.2022 20:57, Daniel P. Smith wrote: >>>>> On 3/29/22 02:43, Jan Beulich wrote: >>>>>> Similarly I don't see how things would work transparently with a >>>>>> Flask policy in place. Regardless of you mentioning the restriction, >>>>>> I think this wants resolving before the patch can go in. >>>>> >>>>> To enable the equivalent in flask would require no hypervisor code >>>>> changes. Instead that would be handled by adding the necessary rules to >>>>> the appropriate flask policy file(s). >>>> >>>> Of course this can be dealt with by adjusting policy file(s), but until >>>> people do so they'd end up with a perceived regression and/or unexplained >>>> difference in behavior from running in dummy (or SILO, once also taken >>>> care of) mode. >>> >>> This need to change the Flask policy is the crux of my dislike for >>> making Xen-internal operations go through XSM checks. It is wrong, >>> IMO, to require the separate policy to grant xen_t permissions for >>> proper operation. I prefer restructuring the code so Xen itself >>> doesn't have to go through XSM checks since that way Xen itself always >>> runs properly regardless of the policy. >>> >>> This is more based on unmap_domain_pirq having an XSM check for an >>> internal operation. dom0less, hyperlaunch, & Live Update may all be >>> niche use cases where requiring a policy change is reasonable. >> >> I will continue to agree with the base logic that today any least >> privilege separation imposed is merely artificial in the face of any >> attack that gains execution control over hypervisor space. What I will >> disagree with is using that as a justification to create tight couplings >> between the internals of the hypervisor that have a potential of causing >> more work in the future when people are looking to use for instance's >> Arms upcoming capability pointers as a real separation enforcement >> mechanisms to de-privilege portions of the hypervisor. >> >> While on principle it is justified to object to having policy statements >> that present a facade, is it not better to look longer term than object >> to some thing on principle based in the now? > > Your claims seem to be speculative about something that doesn't exist, > so I can't evaluate them.
They exists, they are available in OpenPOWER and Arm CHERI is in evaluation now. > Do you envision that this future Xen would have multiple xen_*_t types > requiring explicit Flask policy rules? Right now I would say no for two reasons, first flask comes from the mind set of controlling what hypervisor interfaces a guest may have access and second is that I am not certain whether hypervisor internal contexts should be configurable. v/r, dps
