Re: [RFC 4/6] capabilities: introduce console io as a domain capability

[Julien Grall <julien@xxxxxxx>]

Hi Daniel,

On 08/08/2023 23:31, Daniel P. Smith wrote:
> On 8/3/23 17:24, Julien Grall wrote:
> > Hi Daniel,
> >
> > On 03/08/2023 16:41, Daniel P. Smith wrote:
> > > On 8/1/23 21:01, Stefano Stabellini wrote:
> > > > On Tue, 1 Aug 2023, Daniel P. Smith wrote:
> > > > > patch the field is renamed to capabilities to encapsulate the 
> > > > > capabilities a
> > > > > domain has been granted. The first capability being the ability to 
> > > > > read/write
> > > > > the Xen console.
> > > > >
> > > > > Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> > > > Patch looks fine to me aside the two minor nits. I am not sure I
> > > > understand 100% the difference between capabilities and roles but I am
> > > > OK with the patch. I'd like to hear Julien's feedback on this as well.
> > > This might be worth a section in the hypervisor-guide. As mentioned 
> > > in the cover letter, this was originally proposed as being under XSM. 
> > > A challenge I ran into is that, depending on your view, the 
> > > `is_privileged` field and `hardware_domain` global were either abused 
> > > as a function check and a non-resource privilege check or are just 
> > > multifaceted variables. This is why the concept of the role was 
> > > struck upon, it is more intuitive (for me at least) that have a role 
> > > is something that imparts accesses (privilege checks) and dictates 
> > > hypervisor behaviors when handling the domain (function checks). This 
> > > then brings us to an access or behavior that may be inherent to some 
> > > role(s) but may want to grant on an individually to a guest. A prime 
> > > example of this is console_io, for which it is inherent that the 
> > > hardware domain role will have access but may want to grant to a 
> > > guest without granting it an entire role. This is why I provided for 
> > > identifying these capabilities so that they may be assigned 
> > > individually to a domain.
> > Thanks for the explanation. Just to confirm my understanding, what you 
> > are suggesting is that for a given role, a domain will at least have 
> > the matching capabilities (more could be granted). Is that correct?
> > If so, this wouldn't this mean we can remove d->role and simply use 
> > d->capabilities?
> We could start out with CAP_CTRL and CAP_HW, but it is a little 
> illogical. For instance, control domain has many capabilities, they just 
> have never been fully broken out. XSM did some, but the focus there was 
> just on system resources. Similar with the hardware domain. You are 
> right that it would better deal with the limited number of bits 
> currently available.
> > > While the role/capability is a natural progression from how the 
> > > hypervisor currently operates. Another approach that could be 
> > > consider to deliver a similar experience would be to break down every 
> > > access and function into a capability and then define the standard 
> > > roles as a conglomeration of certain capabilities.
> > At least from the explanation above, I think it would make sense to 
> > break down role to multiple capabilities.
> Would it be acceptable to do this incrementally over time as we are able 
> to determine what needs to be broken out as a distinct capability?
I would be fine with that. Note that some care will be needed for the 
Device-Tree to either version the capabilities or at least not break 
boot when using an old DT on a new Xen.
Cheers,

--
Julien Grall