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 <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?
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