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

[Julien Grall <julien@xxxxxxx>]

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?
> 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.
Cheers,

--
Julien Grall