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 <dpsm...@apertussolutions.com>
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