On 08/22/2018 01:11 PM, Halil Pasic wrote:
On 08/22/2018 05:48 PM, Christian Borntraeger wrote:
On 08/22/2018 05:34 PM, Pierre Morel wrote:
On 22/08/2018 17:11, Christian Borntraeger wrote:
On 08/22/2018 01:03 PM, Pierre Morel wrote:
That's interesting.
IMHO this quote is quite a half-full half-empty cup one:
* it mandates the set of usage domains is a subset of the set
of the control domains, but
* it speaks of independent controls, namely about the 'usage
domain index'
and the 'control domain index list' and makes the enforcement of
the rule
a job of the administrator (instead of codifying it in the
controls).
I'm wondering if a configuration with a usage domain that is not
also a
control domain is rejected outright? Anybody tried that? :)
Yes, and no it is not.
We can use a queue (usage domain) to a AP card for SHA-512 or RSA
without
having to define the queue as a control domain.
Huh? My HMC allows to add a domain as
- control only domain
- control and usage domain.
But I am not able to configure a usage-only domain for my LPAR.
That seems to match
the current code, no?
Yes, it may not be configurable by the HMC but if we start a guest
with no control domain it is not a problem to access the hardware
through the usage domain.
I tested this a long time ago, but tested again today to be sure on
my LPAR.
AFAIU adding a control only domain and a control and usage domain
allows say:
control and usage domain 1
control only domain 2
Allow to send a message to domain 2 using queue 1
Allow also to send a domain modifying message to domain 1 using queue 1
control domain are domain which are controlled
So you have changed the code to not automatically make a usage domain a
control domain in the bitfield (and you could still use it as a usage
domain). Correct?
I tested basically the same yesterday, with the same results.
I think this is probably expected. the "usage implies control" seems to
be a convention implemented by HMC (lpar) and z/VM but millicode offers
the bits to have usage-only domains. As LPAR and z/VM will always enable
any usage-domain to also be a control domain we should do the same.
I'm fine either way, but slightly prefer higher level management software
and not the kernel accommodating this convention.
Please consider a quote from Harald's mail in another sub-thread
"""
... about control domains
Talked with the s390 firmware guys. The convention that the control
domain
mask is a superset of the usage domain mask is only true for 1st level
guests.
It is absolutely valid to run a kvm guest with restricted control domain
mask bitmap in the CRYCB. It is valid to have an empty control domain
mask
and the guest should be able to run crypto CPRBs on the usage
domain(s) without
any problems. However, nobody has tried this.
"""
I'm yet to get an explanation why was this convention established in
the first
place. And I can not figure it out myself. For me a setup where I know
that
the domains used by some guest can not be modified by the same guest
makes
perfect sense. If I try to think in analogies, I kind of compare
modification
(that is control domain) with write access, and usage (that is usage
domain)
with read access to, let's say a regular file. For me, all options
(rw, r, and w)
do make sense, and if I had to pick the one that makes the least sense
I would
pick write only. The convention is in these terms making read-only
illegal. But
should 'usage only domains' ever get identified as something somebody
wants to do
we can just add an attribute for that. So I'm fine either way.
One of the things I suggested in a private conversation with Christian
earlier
today was to provide an additional rw sysfs attribute - a boolean - that
indicates
whether all usage domains should also be control domains. The default
could be
true. This would allow one to configure guests with usage-only domains
as well
as satisfy the convention.
Still I find the commit message for this patch, the implementation of
assign_control_domain() and also the documentation slightly misleading
regarding
what does one get from assign_domain.
Regards,
Halil
It seems that the HMC enforce the LPARs to have access to their
usage domain (AFAIU from Harald)
