On 08/23/2018 09:32 AM, Volodymyr Babchuk wrote:
Hello Daniel,
On 23.08.18 01:44, DeGraaf, Daniel G wrote:
From: Volodymyr Babchuk <volodymyr_babc...@epam.com>
Sent: Wednesday, August 22, 2018 10:12 AM
As we don't want any guest to access limited resources of TEE, we need a way to
control who can work with it.
Thus, new access vector class "tee" is added with only ony operation "call" so
far. tee framework uses this to check if guest has a right
to work with TEE.
Also, example security context domU_with_tee_t was added.
Are you planning to add more access vectors to this class in the future?
Otherwise, it probably doesn't need its own class - since you use xen_t as the
target, placing it in class xen/xen2 is preferred (like tmem and others are
now).
At the moment I can't imagine any other vectors. Reason I created a new class
is that it seemed wrong to me to use generic xen/xen2 class, because, strictly
speaking, this vector have nothing to do with xen core.
But, if you think that it is appropriate to have vector "tee_call" in xen2
class, then I can move it there.
Actually, upon further thought it may better fit in the resource class:
there are already "resource use" and "resource setup" permissions there
that deal with some platform-wide objects. If there will only ever be
one TEE device, a tee_call permission with target xen_t will cover it,
but this allows for a more natural extension to multiple TEEs (or a TEE
with some hypervisor-inspected function-level access control) that are
themselves labeled like we do for PCI devices. That's probably not
relevant to this design until someone makes such an interface, however,
so I'd continue using xen_t until then.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
