On 18/12/2024 17:26, Daniel P. Smith wrote:
>
>
> Hey Michal,
>
> On 12/18/24 06:04, Michal Orzel wrote:
>> Hi Daniel,
>>
>> On 18/12/2024 02:17, Daniel P. Smith wrote:
>>>
>>>
>>>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>>>> Allow to build ARM configuration with support for initializing
>>>>> hardware domain.
>>>>> On ARM it is only possible to start hardware domain in multiboot mode, so
>>>>> dom0less support is required. This is reflected by dependency on
>>>>> DOM0LESS_BOOT
>>>>> instead of directly depending on ARM config option.
>>>
>>>
>>> Just to make sure my assumption is correct, you are looking to do a
>>> multi-domain construction at boot time, with at least two domains. One
>>> of those two domains is the "control domain" and one is the "hardware
>>> domain", aka late hwdom except it's not constructed "late".
>>>
>>> If you want such a configuration, I would highly recommend you first
>>> enable setting flask labels via dom0less (assuming it is not there)
>> Speaking about dom0less and FLASK. A year ago, I did sent you (privately,
>> through
>> AMD hyperlaunch collab) my attempt to add minimal steps to enable setting
>> FLASK policy
>> for dom0less domUs. You then told me that you have a slightly different
>> vision on how it
>> should be done. Any update with that regard? TBH I though that you're going
>> to add this
>> support together with other hyperlaunch patches.
>
> As I mentioned back in my March response, the concern I have with the
> patch you provided was with the layering violation. A security label is
> a flask-centric concept, at least currently, and thus not a concept you
> want to expose in the general XSM api. The correct way to get an XSM
> module's specific info, or translation, is to use the xsm_do_xsm_op(). I
> do feel that xsm_do_xsm_op() has a laying violation in its
> implementation, and is what I want to fix, it is still the correct
> interface. Priorities in meeting the core requirements AMD needs from
> hyperlaunch resulted in several abilities to fall to the wayside for the
> time being. I understand things need to move along, so I would prefer
> the use of existing interface that can be just updated when
> xsm_do_xsm_op() does get fixed up.
xsm_do_xsm_op() is made as an interface between a guest and Xen and is expected
to be
called from within a guest, just like any other hypercall. In dom0less case,
it's Xen who
needs to convert seclabel specified by the user to SID. How do you expect Xen
to use
xsm_do_xsm_op()?
~Michal
