| Message ID | 1534196899-16987-13-git-send-email-akrowiak@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | guest dedicated crypto adapters | expand |
On Mon, 13 Aug 2018 17:48:09 -0400 Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote: > From: Tony Krowiak <akrowiak@linux.ibm.com> > > Provides the sysfs interfaces for: > > 1. Assigning AP control domains to the mediated matrix device > > 2. Unassigning AP control domains from a mediated matrix device > > 3. Displaying the control domains assigned to a mediated matrix > device > > The IDs of the AP control domains assigned to the mediated matrix > device are stored in an AP domain mask (ADM). The bits in the ADM, > from most significant to least significant bit, correspond to > AP domain numbers 0 to 255. On some systems, the maximum allowable > domain number may be less than 255 - depending upon the host's > AP configuration - and assignment may be rejected if the input > domain ID exceeds the limit. Please remind me of the relationship between control domains and usage domains... IIRC, usage domains allow both requests and configuration, while control domains allow only configuration, and are by convention a superset of usage domains. Is there a hard requirement somewhere in there, or can the admin cheerfully use different masks for usage domains and control domains without the SIE choking on it?
On 08/20/2018 04:23 PM, Cornelia Huck wrote: > On Mon, 13 Aug 2018 17:48:09 -0400 > Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote: > >> From: Tony Krowiak <akrowiak@linux.ibm.com> >> >> Provides the sysfs interfaces for: >> >> 1. Assigning AP control domains to the mediated matrix device >> >> 2. Unassigning AP control domains from a mediated matrix device >> >> 3. Displaying the control domains assigned to a mediated matrix >> device >> >> The IDs of the AP control domains assigned to the mediated matrix >> device are stored in an AP domain mask (ADM). The bits in the ADM, >> from most significant to least significant bit, correspond to >> AP domain numbers 0 to 255. On some systems, the maximum allowable >> domain number may be less than 255 - depending upon the host's >> AP configuration - and assignment may be rejected if the input >> domain ID exceeds the limit. > > Please remind me of the relationship between control domains and usage > domains... IIRC, usage domains allow both requests and configuration, > while control domains allow only configuration, and are by convention a > superset of usage domains. > The whole terminology with control and usage domains is IMHO a bit confusing. With the HMC one can assign a domain either as a 'Control' or as a 'Control and Usage' domain. Regarding the masks in the CRYCB, the AQM controls 'using' the domain (e.g. if AQM bit is zero NQAP will refuse to enqueue on that queue) while ADM tells if the guest is allowed to 'change' the given domain. Whether a command-request is of type 'using' or 'changing' is a property of the command request. You can think of 'using' a domain like signing stuff with a key residing within the domain, and of 'changing' a domain like issuing a command to generate a new key for the given domain. > Is there a hard requirement somewhere in there, or can the admin > cheerfully use different masks for usage domains and control domains > without the SIE choking on it? > It is a convention. AFAIR it ain't architecture. SIE won't choke on it I've tried it out. I was arguing along the lines that the kernel should not enforce this convention -- tooling can still do that if we want this enforced. Regards, Halil
On 08/20/2018 10:23 AM, Cornelia Huck wrote: > On Mon, 13 Aug 2018 17:48:09 -0400 > Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote: > >> From: Tony Krowiak <akrowiak@linux.ibm.com> >> >> Provides the sysfs interfaces for: >> >> 1. Assigning AP control domains to the mediated matrix device >> >> 2. Unassigning AP control domains from a mediated matrix device >> >> 3. Displaying the control domains assigned to a mediated matrix >> device >> >> The IDs of the AP control domains assigned to the mediated matrix >> device are stored in an AP domain mask (ADM). The bits in the ADM, >> from most significant to least significant bit, correspond to >> AP domain numbers 0 to 255. On some systems, the maximum allowable >> domain number may be less than 255 - depending upon the host's >> AP configuration - and assignment may be rejected if the input >> domain ID exceeds the limit. > Please remind me of the relationship between control domains and usage > domains... IIRC, usage domains allow both requests and configuration, > while control domains allow only configuration, and are by convention a > superset of usage domains. A usage domain is a domain to which an AP command-request message can be submitted for processing. A control domain is a domain that can be changed by an AP command request message submitted to a usage domain. AP command request messages to configure a domain will contain the domain number of the domain to be modified. The AP firmware will check the control domain mask (ADM) and will allow the request to proceed only if the corresponding bit in the ADM is set. > > Is there a hard requirement somewhere in there, or can the admin > cheerfully use different masks for usage domains and control domains > without the SIE choking on it? There is no hard requirement that control domains must be a superset of the usage domains, it is merely an architectural convention. AFAIK, SIE doesn't enforce this and will not break if the convention is not enforced externally. Having said that, you should note that the AQM and ADM masks configured for the mediated matrix device will be logically OR'd together to create the ADM stored in the CRYCB referenced from the guest's SIE state description. In other words, we are enforcing the convention in our software. >
On Mon, 20 Aug 2018 13:41:32 -0400 Tony Krowiak <akrowiak@linux.ibm.com> wrote: > On 08/20/2018 10:23 AM, Cornelia Huck wrote: > > On Mon, 13 Aug 2018 17:48:09 -0400 > > Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote: > > > >> From: Tony Krowiak <akrowiak@linux.ibm.com> > >> > >> Provides the sysfs interfaces for: > >> > >> 1. Assigning AP control domains to the mediated matrix device > >> > >> 2. Unassigning AP control domains from a mediated matrix device > >> > >> 3. Displaying the control domains assigned to a mediated matrix > >> device > >> > >> The IDs of the AP control domains assigned to the mediated matrix > >> device are stored in an AP domain mask (ADM). The bits in the ADM, > >> from most significant to least significant bit, correspond to > >> AP domain numbers 0 to 255. On some systems, the maximum allowable > >> domain number may be less than 255 - depending upon the host's > >> AP configuration - and assignment may be rejected if the input > >> domain ID exceeds the limit. > > Please remind me of the relationship between control domains and usage > > domains... IIRC, usage domains allow both requests and configuration, > > while control domains allow only configuration, and are by convention a > > superset of usage domains. > > A usage domain is a domain to which an AP command-request message can be > submitted for processing. A control domain is a domain that can > be changed by an AP command request message submitted to a usage domain. > AP command request messages to configure a domain will contain the domain > number of the domain to be modified. The AP firmware will check the > control domain mask (ADM) and will allow the request to proceed only if > the corresponding bit in the ADM is set. Thanks to you and Halil for the explanation. > > > > > Is there a hard requirement somewhere in there, or can the admin > > cheerfully use different masks for usage domains and control domains > > without the SIE choking on it? > > There is no hard requirement that control domains must be a superset of > the usage domains, it is merely an architectural convention. AFAIK, > SIE doesn't enforce this and will not break if the convention is not > enforced externally. Having said that, you should note that the AQM > and ADM masks configured for the mediated matrix device will be logically > OR'd together to create the ADM stored in the CRYCB referenced from the > guest's SIE state description. In other words, we are enforcing the > convention in our software. Hm, that's interesting, as Halil argued that we should not enforce it in the kernel. Might be somewhat surprising as well. If that is really the way to do it, this needs to be documented clearly.
On 08/21/2018 11:25 AM, Cornelia Huck wrote: > On Mon, 20 Aug 2018 13:41:32 -0400 > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > >> On 08/20/2018 10:23 AM, Cornelia Huck wrote: >>> On Mon, 13 Aug 2018 17:48:09 -0400 >>> Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote: >>> >>>> From: Tony Krowiak <akrowiak@linux.ibm.com> >>>> >>>> Provides the sysfs interfaces for: >>>> >>>> 1. Assigning AP control domains to the mediated matrix device >>>> >>>> 2. Unassigning AP control domains from a mediated matrix device >>>> >>>> 3. Displaying the control domains assigned to a mediated matrix >>>> device >>>> >>>> The IDs of the AP control domains assigned to the mediated matrix >>>> device are stored in an AP domain mask (ADM). The bits in the ADM, >>>> from most significant to least significant bit, correspond to >>>> AP domain numbers 0 to 255. On some systems, the maximum allowable >>>> domain number may be less than 255 - depending upon the host's >>>> AP configuration - and assignment may be rejected if the input >>>> domain ID exceeds the limit. >>> Please remind me of the relationship between control domains and usage >>> domains... IIRC, usage domains allow both requests and configuration, >>> while control domains allow only configuration, and are by convention a >>> superset of usage domains. >> A usage domain is a domain to which an AP command-request message can be >> submitted for processing. A control domain is a domain that can >> be changed by an AP command request message submitted to a usage domain. >> AP command request messages to configure a domain will contain the domain >> number of the domain to be modified. The AP firmware will check the >> control domain mask (ADM) and will allow the request to proceed only if >> the corresponding bit in the ADM is set. > Thanks to you and Halil for the explanation. > >>> Is there a hard requirement somewhere in there, or can the admin >>> cheerfully use different masks for usage domains and control domains >>> without the SIE choking on it? >> There is no hard requirement that control domains must be a superset of >> the usage domains, it is merely an architectural convention. AFAIK, >> SIE doesn't enforce this and will not break if the convention is not >> enforced externally. Having said that, you should note that the AQM >> and ADM masks configured for the mediated matrix device will be logically >> OR'd together to create the ADM stored in the CRYCB referenced from the >> guest's SIE state description. In other words, we are enforcing the >> convention in our software. > Hm, that's interesting, as Halil argued that we should not enforce it > in the kernel. Might be somewhat surprising as well. If that is really > the way to do it, this needs to be documented clearly. This convention has been enforced by the kernel since v1. This is also enforced by both the LPAR as well as in z/VM. The following is from the PR/SM Planning Guide: Control Domain A logical partition's control domains are those cryptographic domains for which remote secure administration functions can be established and administered from this logical partition. This logical partition’s control domains must include its usage domains. For each index selected in the usage domain index list, you must select the same index in the control domain index list Consequently, I'm going to opt for ensuring this is clearly documented. Based on the fact you've requested clarification of many points described in this section of the doc, I think I'll try putting my meager skills as a wordsmith to work to hopefully clarify things. I'll run it by you when I complete that task to see if I've succeeded:) >
On 08/21/2018 07:07 PM, Tony Krowiak wrote: > On 08/21/2018 11:25 AM, Cornelia Huck wrote: >> On Mon, 20 Aug 2018 13:41:32 -0400 >> Tony Krowiak <akrowiak@linux.ibm.com> wrote: >> >>> On 08/20/2018 10:23 AM, Cornelia Huck wrote: >>>> On Mon, 13 Aug 2018 17:48:09 -0400 >>>> Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote: >>>>> From: Tony Krowiak <akrowiak@linux.ibm.com> >>>>> >>>>> Provides the sysfs interfaces for: >>>>> >>>>> 1. Assigning AP control domains to the mediated matrix device >>>>> >>>>> 2. Unassigning AP control domains from a mediated matrix device >>>>> >>>>> 3. Displaying the control domains assigned to a mediated matrix >>>>> device >>>>> >>>>> The IDs of the AP control domains assigned to the mediated matrix >>>>> device are stored in an AP domain mask (ADM). The bits in the ADM, >>>>> from most significant to least significant bit, correspond to >>>>> AP domain numbers 0 to 255. On some systems, the maximum allowable >>>>> domain number may be less than 255 - depending upon the host's >>>>> AP configuration - and assignment may be rejected if the input >>>>> domain ID exceeds the limit. >>>> Please remind me of the relationship between control domains and usage >>>> domains... IIRC, usage domains allow both requests and configuration, >>>> while control domains allow only configuration, and are by convention a >>>> superset of usage domains. >>> A usage domain is a domain to which an AP command-request message can be >>> submitted for processing. A control domain is a domain that can >>> be changed by an AP command request message submitted to a usage domain. >>> AP command request messages to configure a domain will contain the domain >>> number of the domain to be modified. The AP firmware will check the >>> control domain mask (ADM) and will allow the request to proceed only if >>> the corresponding bit in the ADM is set. >> Thanks to you and Halil for the explanation. >> >>>> Is there a hard requirement somewhere in there, or can the admin >>>> cheerfully use different masks for usage domains and control domains >>>> without the SIE choking on it? >>> There is no hard requirement that control domains must be a superset of >>> the usage domains, it is merely an architectural convention. AFAIK, >>> SIE doesn't enforce this and will not break if the convention is not >>> enforced externally. Having said that, you should note that the AQM >>> and ADM masks configured for the mediated matrix device will be logically >>> OR'd together to create the ADM stored in the CRYCB referenced from the >>> guest's SIE state description. In other words, we are enforcing the >>> convention in our software. >> Hm, that's interesting, as Halil argued that we should not enforce it >> in the kernel. Might be somewhat surprising as well. If that is really >> the way to do it, this needs to be documented clearly. > > This convention has been enforced by the kernel since v1. This is also > enforced by both the LPAR as well as in z/VM. The following is from the > PR/SM Planning Guide: > > Control Domain > A logical partition's control domains are those cryptographic domains for which remote secure > administration functions can be established and administered from this logical partition. This > logical partition’s control domains must include its usage domains. For each index selected in the > usage domain index list, you must select the same index in the control domain index list > 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). > > Consequently, I'm going to opt for ensuring this is clearly documented. Based on the fact you've > requested clarification of many points described in this section of the doc, I > think I'll try putting my meager skills as a wordsmith to work to hopefully clarify things. > I'll run it by you when I complete that task to see if I've succeeded:) I don't think just a doc update will do. Let me explain why. What describe as "... note that the AQM and ADM masks configured for the mediated matrix device will be logically OR'd together to create the ADM stored in the CRYCB referenced from the guest's SIE state description." is a gotcha at best. The member of struct ap_matrix and the member of the respective apcb in the crycb are both called 'adm', but ap_matrix.adm is not an ADM as we know it from the architecture, but rather ~ AQM & ADM. I feel pretty strongly about this one. If we want to keep the enforcement in the kernel, I guess, the assign_domain should set the bit corresponding bit not only in ap_matrix.aqm but also in ap_matrix.adm. When the ap_matrix is committed into the crycb no further manipulating the masks should take place. I don't feel strongly about whether to enforce this convention about AQM and ADM in the kernel or not. Frankly, I don't know what is behind the rule. Since I can't tell if any problems are to be expected if this convention is violated, I would feel more comfortable if the rule was accommodated higher in the management stack. Regards, Halil > >> >
On Wed, 22 Aug 2018 01:18:20 +0200 Halil Pasic <pasic@linux.ibm.com> wrote: > On 08/21/2018 07:07 PM, Tony Krowiak wrote: > > This convention has been enforced by the kernel since v1. This is also > > enforced by both the LPAR as well as in z/VM. The following is from the > > PR/SM Planning Guide: > > > > Control Domain > > A logical partition's control domains are those cryptographic domains for which remote secure > > administration functions can be established and administered from this logical partition. This > > logical partition’s control domains must include its usage domains. For each index selected in the > > usage domain index list, you must select the same index in the control domain index list > > 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? :) > > > > > Consequently, I'm going to opt for ensuring this is clearly documented. Based on the fact you've > > requested clarification of many points described in this section of the doc, I > > think I'll try putting my meager skills as a wordsmith to work to hopefully clarify things. > > I'll run it by you when I complete that task to see if I've succeeded:) > > I don't think just a doc update will do. Let me explain why. > > What describe as "... note that the AQM and ADM masks configured for the > mediated matrix device will be logically OR'd together to create the ADM > stored in the CRYCB referenced from the guest's SIE state description." > is a gotcha at best. The member of struct ap_matrix and the member of the > respective apcb in the crycb are both called 'adm', but ap_matrix.adm is > not an ADM as we know it from the architecture, but rather ~ AQM & ADM. > > I feel pretty strongly about this one. If we want to keep the enforcement > in the kernel, I guess, the assign_domain should set the bit corresponding > bit not only in ap_matrix.aqm but also in ap_matrix.adm. When the > ap_matrix is committed into the crycb no further manipulating the masks > should take place. Would you be fine if the control domain interface stated that it is used to configure _additional_ control domains and the usage domain interface stated that it is used to define usage and implicitly also control domains? (And make the usage domain interface also set the equivalent bit in the control domain mask.) > > I don't feel strongly about whether to enforce this convention about AQM > and ADM in the kernel or not. Frankly, I don't know what is behind the > rule. Since I can't tell if any problems are to be expected if this > convention is violated, I would feel more comfortable if the rule was > accommodated higher in the management stack. I guess it depends: - If this is a case of: "Don't configure control domains that are not also usage domains. You are likely to go through {code,firmware,hardware} paths that are generally not used.", configure it in the kernel. - If this rather is "Everybody is doing that, it's a general convention.", configure it higher up in the stack (libvirt?)
On 08/22/2018 11:42 AM, Cornelia Huck wrote: > On Wed, 22 Aug 2018 01:18:20 +0200 > Halil Pasic <pasic@linux.ibm.com> wrote: > >> On 08/21/2018 07:07 PM, Tony Krowiak wrote: >>> This convention has been enforced by the kernel since v1. This is also >>> enforced by both the LPAR as well as in z/VM. The following is from the >>> PR/SM Planning Guide: >>> >>> Control Domain >>> A logical partition's control domains are those cryptographic domains for which remote secure >>> administration functions can be established and administered from this logical partition. This >>> logical partition’s control domains must include its usage domains. For each index selected in the >>> usage domain index list, you must select the same index in the control domain index list >>> > > 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? :) > I did not. This is my first exposure to the PR/SM Planning Guide. As I stated previously the HMC interface enforces the convention by UI design: in the activation profile you can either configure a domain as 'control' or 'control and usage' domain -- think radio button. I have no idea how is this information feed into PR/SM and same goes for alternatives to specify it. So I'm also very curious about this. Another interesting question: On what level does z/VM and PR/SM enforce the convention (i.e. on privilege level does the code doing the enforcement run)? >> >>> >>> Consequently, I'm going to opt for ensuring this is clearly documented. Based on the fact you've >>> requested clarification of many points described in this section of the doc, I >>> think I'll try putting my meager skills as a wordsmith to work to hopefully clarify things. >>> I'll run it by you when I complete that task to see if I've succeeded:) >> >> I don't think just a doc update will do. Let me explain why. >> >> What describe as "... note that the AQM and ADM masks configured for the >> mediated matrix device will be logically OR'd together to create the ADM >> stored in the CRYCB referenced from the guest's SIE state description." >> is a gotcha at best. The member of struct ap_matrix and the member of the >> respective apcb in the crycb are both called 'adm', but ap_matrix.adm is >> not an ADM as we know it from the architecture, but rather ~ AQM & ADM. >> >> I feel pretty strongly about this one. If we want to keep the enforcement >> in the kernel, I guess, the assign_domain should set the bit corresponding >> bit not only in ap_matrix.aqm but also in ap_matrix.adm. When the >> ap_matrix is committed into the crycb no further manipulating the masks >> should take place. > > Would you be fine if the control domain interface stated that it is > used to configure _additional_ control domains and the usage domain > interface stated that it is used to define usage and implicitly also > control domains? (And make the usage domain interface also set the > equivalent bit in the control domain mask.) > I'm fine with the interface, otherwise I would not have r-b-ed the patch. What I strongly dislike is the implementation is IMHO very confusing (along the lines "surprise, surprise it is called adm but it ain't adm"). This implementation detail however can be changed any time, so I did not want to start a big discussion as we wanted to get this out ASAP. But since it was brought up, I decided to put in my two cents. >> >> I don't feel strongly about whether to enforce this convention about AQM >> and ADM in the kernel or not. Frankly, I don't know what is behind the >> rule. Since I can't tell if any problems are to be expected if this >> convention is violated, I would feel more comfortable if the rule was >> accommodated higher in the management stack. > > I guess it depends: > > - If this is a case of: "Don't configure control domains that are not > also usage domains. You are likely to go through > {code,firmware,hardware} paths that are generally not used.", > configure it in the kernel. > - If this rather is "Everybody is doing that, it's a general > convention.", configure it higher up in the stack (libvirt?) > My guess is that it's the second, but I really don't know. Maybe somebody else will help us answer this question, and also tell what is the rationale behind the rule. Regards, Halil
On 22/08/2018 11:42, Cornelia Huck wrote: > On Wed, 22 Aug 2018 01:18:20 +0200 > Halil Pasic <pasic@linux.ibm.com> wrote: > >> On 08/21/2018 07:07 PM, Tony Krowiak wrote: >>> This convention has been enforced by the kernel since v1. This is also >>> enforced by both the LPAR as well as in z/VM. The following is from the >>> PR/SM Planning Guide: >>> >>> Control Domain >>> A logical partition's control domains are those cryptographic domains for which remote secure >>> administration functions can be established and administered from this logical partition. This >>> logical partition’s control domains must include its usage domains. For each index selected in the >>> usage domain index list, you must select the same index in the control domain index list >>> > 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. Regards, Pierre
On 08/21/2018 07:18 PM, Halil Pasic wrote: > > > On 08/21/2018 07:07 PM, Tony Krowiak wrote: >> On 08/21/2018 11:25 AM, Cornelia Huck wrote: >>> On Mon, 20 Aug 2018 13:41:32 -0400 >>> Tony Krowiak <akrowiak@linux.ibm.com> wrote: >>> >>>> On 08/20/2018 10:23 AM, Cornelia Huck wrote: >>>>> On Mon, 13 Aug 2018 17:48:09 -0400 >>>>> Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote: >>>>>> From: Tony Krowiak <akrowiak@linux.ibm.com> >>>>>> >>>>>> Provides the sysfs interfaces for: >>>>>> >>>>>> 1. Assigning AP control domains to the mediated matrix device >>>>>> >>>>>> 2. Unassigning AP control domains from a mediated matrix device >>>>>> >>>>>> 3. Displaying the control domains assigned to a mediated matrix >>>>>> device >>>>>> >>>>>> The IDs of the AP control domains assigned to the mediated matrix >>>>>> device are stored in an AP domain mask (ADM). The bits in the ADM, >>>>>> from most significant to least significant bit, correspond to >>>>>> AP domain numbers 0 to 255. On some systems, the maximum allowable >>>>>> domain number may be less than 255 - depending upon the host's >>>>>> AP configuration - and assignment may be rejected if the input >>>>>> domain ID exceeds the limit. >>>>> Please remind me of the relationship between control domains and >>>>> usage >>>>> domains... IIRC, usage domains allow both requests and configuration, >>>>> while control domains allow only configuration, and are by >>>>> convention a >>>>> superset of usage domains. >>>> A usage domain is a domain to which an AP command-request message >>>> can be >>>> submitted for processing. A control domain is a domain that can >>>> be changed by an AP command request message submitted to a usage >>>> domain. >>>> AP command request messages to configure a domain will contain the >>>> domain >>>> number of the domain to be modified. The AP firmware will check the >>>> control domain mask (ADM) and will allow the request to proceed >>>> only if >>>> the corresponding bit in the ADM is set. >>> Thanks to you and Halil for the explanation. >>> >>>>> Is there a hard requirement somewhere in there, or can the admin >>>>> cheerfully use different masks for usage domains and control domains >>>>> without the SIE choking on it? >>>> There is no hard requirement that control domains must be a >>>> superset of >>>> the usage domains, it is merely an architectural convention. AFAIK, >>>> SIE doesn't enforce this and will not break if the convention is not >>>> enforced externally. Having said that, you should note that the AQM >>>> and ADM masks configured for the mediated matrix device will be >>>> logically >>>> OR'd together to create the ADM stored in the CRYCB referenced from >>>> the >>>> guest's SIE state description. In other words, we are enforcing the >>>> convention in our software. >>> Hm, that's interesting, as Halil argued that we should not enforce it >>> in the kernel. Might be somewhat surprising as well. If that is really >>> the way to do it, this needs to be documented clearly. >> >> This convention has been enforced by the kernel since v1. This is also >> enforced by both the LPAR as well as in z/VM. The following is from the >> PR/SM Planning Guide: >> >> Control Domain >> A logical partition's control domains are those cryptographic domains >> for which remote secure >> administration functions can be established and administered from >> this logical partition. This >> logical partition’s control domains must include its usage domains. >> For each index selected in the >> usage domain index list, you must select the same index in the >> control domain index list >> > > 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). For what it's worth, I spoke with the z/VM developers about dedicated crypto in z/VM. In z/VM dedicated crypto, control domains are not even configured by the admin. All configured usage domains are also configured as control domains. > > >> >> Consequently, I'm going to opt for ensuring this is clearly >> documented. Based on the fact you've >> requested clarification of many points described in this section of >> the doc, I >> think I'll try putting my meager skills as a wordsmith to work to >> hopefully clarify things. >> I'll run it by you when I complete that task to see if I've succeeded:) > > I don't think just a doc update will do. Let me explain why. > > What describe as "... note that the AQM and ADM masks configured for the > mediated matrix device will be logically OR'd together to create the ADM > stored in the CRYCB referenced from the guest's SIE state description." > is a gotcha at best. The member of struct ap_matrix and the member of the > respective apcb in the crycb are both called 'adm', but ap_matrix.adm is > not an ADM as we know it from the architecture, but rather ~ AQM & ADM. > > I feel pretty strongly about this one. If we want to keep the enforcement > in the kernel, I guess, the assign_domain should set the bit > corresponding > bit not only in ap_matrix.aqm but also in ap_matrix.adm. When the > ap_matrix is committed into the crycb no further manipulating the masks > should take place. I have no problem with this and considered implementing it that way at one time. > > I don't feel strongly about whether to enforce this convention about AQM > and ADM in the kernel or not. Frankly, I don't know what is behind the > rule. Since I can't tell if any problems are to be expected if this > convention is violated, I would feel more comfortable if the rule was > accommodated higher in the management stack. I wouldn't describe it as a rule. It is described in the architecture doc as an architectural convention; in other words, it is agreed upon that all usage domains should also be control domains. Based on my discussions with the z/VM developers, I believe the reason for the convention is to ensure a system has control over its own usage domains, but that is just my interpretation. > > > Regards, > Halil > >> >>> >>
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?
On 08/22/2018 05:42 AM, Cornelia Huck wrote: > On Wed, 22 Aug 2018 01:18:20 +0200 > Halil Pasic <pasic@linux.ibm.com> wrote: > >> On 08/21/2018 07:07 PM, Tony Krowiak wrote: >>> This convention has been enforced by the kernel since v1. This is also >>> enforced by both the LPAR as well as in z/VM. The following is from the >>> PR/SM Planning Guide: >>> >>> Control Domain >>> A logical partition's control domains are those cryptographic domains for which remote secure >>> administration functions can be established and administered from this logical partition. This >>> logical partition’s control domains must include its usage domains. For each index selected in the >>> usage domain index list, you must select the same index in the control domain index list >>> > 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? :) That's been tried and is not rejected. > >>> Consequently, I'm going to opt for ensuring this is clearly documented. Based on the fact you've >>> requested clarification of many points described in this section of the doc, I >>> think I'll try putting my meager skills as a wordsmith to work to hopefully clarify things. >>> I'll run it by you when I complete that task to see if I've succeeded:) >> I don't think just a doc update will do. Let me explain why. >> >> What describe as "... note that the AQM and ADM masks configured for the >> mediated matrix device will be logically OR'd together to create the ADM >> stored in the CRYCB referenced from the guest's SIE state description." >> is a gotcha at best. The member of struct ap_matrix and the member of the >> respective apcb in the crycb are both called 'adm', but ap_matrix.adm is >> not an ADM as we know it from the architecture, but rather ~ AQM & ADM. >> >> I feel pretty strongly about this one. If we want to keep the enforcement >> in the kernel, I guess, the assign_domain should set the bit corresponding >> bit not only in ap_matrix.aqm but also in ap_matrix.adm. When the >> ap_matrix is committed into the crycb no further manipulating the masks >> should take place. > Would you be fine if the control domain interface stated that it is > used to configure _additional_ control domains and the usage domain > interface stated that it is used to define usage and implicitly also > control domains? (And make the usage domain interface also set the > equivalent bit in the control domain mask.) I think that is the better way to go and is something Halil recommended in another post. > >> I don't feel strongly about whether to enforce this convention about AQM >> and ADM in the kernel or not. Frankly, I don't know what is behind the >> rule. Since I can't tell if any problems are to be expected if this >> convention is violated, I would feel more comfortable if the rule was >> accommodated higher in the management stack. > I guess it depends: > > - If this is a case of: "Don't configure control domains that are not > also usage domains. You are likely to go through > {code,firmware,hardware} paths that are generally not used.", > configure it in the kernel. > - If this rather is "Everybody is doing that, it's a general > convention.", configure it higher up in the stack (libvirt?) I have come to the conclusion that the convention should be enforced in the sysfs interfaces of the mediated matrix device as follows: 1. All domains assigned as usage domains will also be implicitly assigned as control domains. 2. Control domains that are not usage domains may be assigned via the assign_control_domain interface. My reason is to maintain consistency across platforms, because: 1. The architecture doc states that control domains are a superset of the usage domains. 2. The HMC interface for assigning domains to the LPAR enforces the convention. 3. The PR/SM documentation states the same. >
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 It seems that the HMC enforce the LPARs to have access to their usage domain (AFAIU from Harald)
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 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. > It seems that the HMC enforce the LPARs to have access to their usage domain (AFAIU from Harald)
On 22/08/2018 17:48, 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? yes and I used Harald's libica tests to verify it in the guest. > 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. > > >> It seems that the HMC enforce the LPARs to have access to their usage domain (AFAIU from Harald)
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. 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) >
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) >>
On 08/22/2018 09:16 PM, Tony Krowiak wrote: > 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. > I prefer keeping the attributes as they are and adding a new let's say (un)assign_usage_domain if the need arises over this boolean attribute that changes how (un)assign_domain works. Halil
On Wed, 22 Aug 2018 15:16:19 -0400 Tony Krowiak <akrowiak@linux.ibm.com> wrote: > 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. Would this additional attribute then control "add usage domains to the list of control domains automatically", or "don't allow to add a usage domain if it has not already been added as a control domain"? One thing I'm still unsure about is how libvirt comes into the picture here. Will it consume the setting, or actively manipulate it? [In general, I'm not very clear about how libvirt will interact with the whole infrastructure...]
On 23/08/2018 11:26, Halil Pasic wrote: > > > On 08/22/2018 09:16 PM, Tony Krowiak wrote: >> 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. >>>>>>>> ... >>>> >>>> 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? Yes. >>> >>> 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 think it is the reasonable thing to do. >>> >>> I'm fine either way, but slightly prefer higher level management >>> software >>> and not the kernel accommodating this convention. Please, we do not need this in a first version just make it easy stick with what HMC does. >>> 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. We do not need to introduce new features now. regards, Pierre
On 23/08/2018 12:25, Cornelia Huck wrote: > On Wed, 22 Aug 2018 15:16:19 -0400 > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > >> 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. > > Would this additional attribute then control "add usage domains to the > list of control domains automatically", or "don't allow to add a usage > domain if it has not already been added as a control domain"? > > One thing I'm still unsure about is how libvirt comes into the picture > here. Will it consume the setting, or actively manipulate it? > > [In general, I'm not very clear about how libvirt will interact with the > whole infrastructure...] > When I read you it convince me that it is not wise to change anything that has been already discuss and could impact the Libvirt. Regards, Pierre
On Thu, 23 Aug 2018 12:43:42 +0200 Pierre Morel <pmorel@linux.ibm.com> wrote: > On 23/08/2018 12:25, Cornelia Huck wrote: > > On Wed, 22 Aug 2018 15:16:19 -0400 > > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > > > >> 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. > > > > Would this additional attribute then control "add usage domains to the > > list of control domains automatically", or "don't allow to add a usage > > domain if it has not already been added as a control domain"? > > > > One thing I'm still unsure about is how libvirt comes into the picture > > here. Will it consume the setting, or actively manipulate it? > > > > [In general, I'm not very clear about how libvirt will interact with the > > whole infrastructure...] > > > > When I read you it convince me that it is not wise to change anything > that has been already discuss and could impact the Libvirt. My main point basically was that we should get feedback from a libvirt POV :) The new attribute may make sense, or not; but I'm really feeling a bit in the dark with regard to libvirt.
On 23/08/2018 13:31, Cornelia Huck wrote: > On Thu, 23 Aug 2018 12:43:42 +0200 > Pierre Morel <pmorel@linux.ibm.com> wrote: > >> On 23/08/2018 12:25, Cornelia Huck wrote: >>> On Wed, 22 Aug 2018 15:16:19 -0400 >>> Tony Krowiak <akrowiak@linux.ibm.com> wrote: >>> >>>> 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. >>> >>> Would this additional attribute then control "add usage domains to the >>> list of control domains automatically", or "don't allow to add a usage >>> domain if it has not already been added as a control domain"? >>> >>> One thing I'm still unsure about is how libvirt comes into the picture >>> here. Will it consume the setting, or actively manipulate it? >>> >>> [In general, I'm not very clear about how libvirt will interact with the >>> whole infrastructure...] >>> >> >> When I read you it convince me that it is not wise to change anything >> that has been already discuss and could impact the Libvirt. > > My main point basically was that we should get feedback from a libvirt > POV :) The new attribute may make sense, or not; but I'm really feeling > a bit in the dark with regard to libvirt. > Me too, this explains my conservative approach ;)
On 08/23/2018 06:25 AM, Cornelia Huck wrote: > On Wed, 22 Aug 2018 15:16:19 -0400 > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > >> 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. > Would this additional attribute then control "add usage domains to the > list of control domains automatically", or "don't allow to add a usage > domain if it has not already been added as a control domain"? It was just a proposal that wasn't really discussed at all, but this attribute would add usage domains to the list of control domains automatically if set to one. That would be the default behavior which would be turned off by manually setting it to zero. > > One thing I'm still unsure about is how libvirt comes into the picture > here. Will it consume the setting, or actively manipulate it? libvirt is not in the picture. The only thing libvirt does is identify which mediated matrix device (i.e., UUID) is to be used by the guest. > > [In general, I'm not very clear about how libvirt will interact with the > whole infrastructure...] The libvirt domain XML will only specify the UUID of the matrix device to be used by the guest. Consequently, libvirt will insert the device statement for the vfio-ap device into the QEMU command line: -device vfio-ap,syfsdev={path-to-mdev} All configuration of the mediated device, including the proposed attribute above, is handled via sysfs attributes. >
On Thu, 23 Aug 2018 10:16:59 -0400 Tony Krowiak <akrowiak@linux.ibm.com> wrote: > On 08/23/2018 06:25 AM, Cornelia Huck wrote: > > On Wed, 22 Aug 2018 15:16:19 -0400 > > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > > > >> 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. > > Would this additional attribute then control "add usage domains to the > > list of control domains automatically", or "don't allow to add a usage > > domain if it has not already been added as a control domain"? > > It was just a proposal that wasn't really discussed at all, but this > attribute would add usage domains to the list of control domains > automatically if set to one. That would be the default behavior which > would be turned off by manually setting it to zero. If we want to do something like that, having it add the usage domains automatically sounds like the more workable alternative. What I like about this is that we make it explicit that we change the masks beyond what the admin explicitly configured, and provide a knob to turn off that behaviour. > > > > > One thing I'm still unsure about is how libvirt comes into the picture > > here. Will it consume the setting, or actively manipulate it? > > libvirt is not in the picture. The only thing libvirt does is identify > which mediated matrix device (i.e., UUID) is to be used by the guest. > > > > > [In general, I'm not very clear about how libvirt will interact with the > > whole infrastructure...] > > The libvirt domain XML will only specify the UUID of the matrix device > to be used by the guest. Consequently, libvirt will insert the device > statement for the vfio-ap device into the QEMU command line: > > -device vfio-ap,syfsdev={path-to-mdev} > > All configuration of the mediated device, including the proposed attribute > above, is handled via sysfs attributes. So, basically, libvirt will only consume what the admin has already configured?
On 08/27/2018 04:33 AM, Cornelia Huck wrote: > On Thu, 23 Aug 2018 10:16:59 -0400 > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > >> On 08/23/2018 06:25 AM, Cornelia Huck wrote: >>> On Wed, 22 Aug 2018 15:16:19 -0400 >>> Tony Krowiak <akrowiak@linux.ibm.com> wrote: >>> >>>> 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. >>> Would this additional attribute then control "add usage domains to the >>> list of control domains automatically", or "don't allow to add a usage >>> domain if it has not already been added as a control domain"? >> It was just a proposal that wasn't really discussed at all, but this >> attribute would add usage domains to the list of control domains >> automatically if set to one. That would be the default behavior which >> would be turned off by manually setting it to zero. > If we want to do something like that, having it add the usage domains > automatically sounds like the more workable alternative. What I like > about this is that we make it explicit that we change the masks beyond > what the admin explicitly configured, and provide a knob to turn off > that behaviour. So, are you saying I should go ahead and implement this? > >>> One thing I'm still unsure about is how libvirt comes into the picture >>> here. Will it consume the setting, or actively manipulate it? >> libvirt is not in the picture. The only thing libvirt does is identify >> which mediated matrix device (i.e., UUID) is to be used by the guest. >> >>> [In general, I'm not very clear about how libvirt will interact with the >>> whole infrastructure...] >> The libvirt domain XML will only specify the UUID of the matrix device >> to be used by the guest. Consequently, libvirt will insert the device >> statement for the vfio-ap device into the QEMU command line: >> >> -device vfio-ap,syfsdev={path-to-mdev} >> >> All configuration of the mediated device, including the proposed attribute >> above, is handled via sysfs attributes. > So, basically, libvirt will only consume what the admin has already > configured? Yes. >
On Mon, 27 Aug 2018 09:47:58 -0400 Tony Krowiak <akrowiak@linux.ibm.com> wrote: > On 08/27/2018 04:33 AM, Cornelia Huck wrote: > > On Thu, 23 Aug 2018 10:16:59 -0400 > > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > > > >> On 08/23/2018 06:25 AM, Cornelia Huck wrote: > >>> On Wed, 22 Aug 2018 15:16:19 -0400 > >>> Tony Krowiak <akrowiak@linux.ibm.com> wrote: > >>> > >>>> 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. > >>> Would this additional attribute then control "add usage domains to the > >>> list of control domains automatically", or "don't allow to add a usage > >>> domain if it has not already been added as a control domain"? > >> It was just a proposal that wasn't really discussed at all, but this > >> attribute would add usage domains to the list of control domains > >> automatically if set to one. That would be the default behavior which > >> would be turned off by manually setting it to zero. > > If we want to do something like that, having it add the usage domains > > automatically sounds like the more workable alternative. What I like > > about this is that we make it explicit that we change the masks beyond > > what the admin explicitly configured, and provide a knob to turn off > > that behaviour. > > So, are you saying I should go ahead and implement this? I'm just saying that it does not sound like a bad idea :) If you agree that it's a good idea and if others also like it... I'd certainly not mind you going ahead :)
On 08/27/2018 03:51 PM, Cornelia Huck wrote: > On Mon, 27 Aug 2018 09:47:58 -0400 > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > >> On 08/27/2018 04:33 AM, Cornelia Huck wrote: >>> On Thu, 23 Aug 2018 10:16:59 -0400 >>> Tony Krowiak <akrowiak@linux.ibm.com> wrote: >>> >>>> On 08/23/2018 06:25 AM, Cornelia Huck wrote: >>>>> On Wed, 22 Aug 2018 15:16:19 -0400 >>>>> Tony Krowiak <akrowiak@linux.ibm.com> wrote: >>>>> >>>>>> 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. >>>>> Would this additional attribute then control "add usage domains to the >>>>> list of control domains automatically", or "don't allow to add a usage >>>>> domain if it has not already been added as a control domain"? >>>> It was just a proposal that wasn't really discussed at all, but this >>>> attribute would add usage domains to the list of control domains >>>> automatically if set to one. That would be the default behavior which >>>> would be turned off by manually setting it to zero. >>> If we want to do something like that, having it add the usage domains >>> automatically sounds like the more workable alternative. What I like >>> about this is that we make it explicit that we change the masks beyond >>> what the admin explicitly configured, and provide a knob to turn off >>> that behaviour. >> >> So, are you saying I should go ahead and implement this? > > I'm just saying that it does not sound like a bad idea :) > > If you agree that it's a good idea and if others also like it... I'd > certainly not mind you going ahead :) > I can live with it. What I don't like about it is that it adds more context dependent semantics. The same sequence of actions results in a different result (depending on the mode of operation). Regards, Halil
On 08/27/2018 09:51 AM, Cornelia Huck wrote: > On Mon, 27 Aug 2018 09:47:58 -0400 > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > >> On 08/27/2018 04:33 AM, Cornelia Huck wrote: >>> On Thu, 23 Aug 2018 10:16:59 -0400 >>> Tony Krowiak <akrowiak@linux.ibm.com> wrote: >>> >>>> On 08/23/2018 06:25 AM, Cornelia Huck wrote: >>>>> On Wed, 22 Aug 2018 15:16:19 -0400 >>>>> Tony Krowiak <akrowiak@linux.ibm.com> wrote: >>>>> >>>>>> 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. >>>>> Would this additional attribute then control "add usage domains to the >>>>> list of control domains automatically", or "don't allow to add a usage >>>>> domain if it has not already been added as a control domain"? >>>> It was just a proposal that wasn't really discussed at all, but this >>>> attribute would add usage domains to the list of control domains >>>> automatically if set to one. That would be the default behavior which >>>> would be turned off by manually setting it to zero. >>> If we want to do something like that, having it add the usage domains >>> automatically sounds like the more workable alternative. What I like >>> about this is that we make it explicit that we change the masks beyond >>> what the admin explicitly configured, and provide a knob to turn off >>> that behaviour. >> So, are you saying I should go ahead and implement this? > I'm just saying that it does not sound like a bad idea :) > > If you agree that it's a good idea and if others also like it... I'd > certainly not mind you going ahead :) This was discussed with out crypto team and hardware architects and it was decided that configuring all usage domains as control domains also is not the right thing to do, so only domains assigned as control domains will be set in the ADM field of the the guest's CRYCB. >
diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c index c4d7504..f732177 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -447,11 +447,119 @@ static ssize_t unassign_domain_store(struct device *dev, } DEVICE_ATTR_WO(unassign_domain); +/** + * assign_control_domain_store + * + * @dev: the matrix device + * @attr: the mediated matrix device's assign_control_domain attribute + * @buf: a buffer containing the domain ID to be assigned + * @count: the number of bytes in @buf + * + * Parses the domain ID from @buf and assigns it to the mediated matrix device. + * + * Returns the number of bytes processed if the domain ID is valid; otherwise + * returns an error. + */ +static ssize_t assign_control_domain_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + int ret; + unsigned long id; + struct mdev_device *mdev = mdev_from_dev(dev); + struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); + unsigned long maxid = matrix_mdev->matrix.adm_max; + + ret = kstrtoul(buf, 0, &id); + if (ret) + return ret; + + if (id > maxid) + ret = -EINVAL; + + /* Set the bit in the ADM (bitmask) corresponding to the AP control + * domain number (id). The bits in the mask, from most significant to + * least significant, correspond to IDs 0 up to the one less than the + * number of control domains that can be assigned. + */ + mutex_lock(&matrix_dev.lock); + set_bit_inv(id, matrix_mdev->matrix.adm); + mutex_unlock(&matrix_dev.lock); + + return count; +} +DEVICE_ATTR_WO(assign_control_domain); + +/** + * unassign_control_domain_store + * + * @dev: the matrix device + * @attr: the mediated matrix device's unassign_control_domain attribute + * @buf: a buffer containing the domain ID to be assigned + * @count: the number of bytes in @buf + * + * Parses the domain ID from @buf and unassigns it from the mediated matrix + * device. + * + * Returns the number of bytes processed if the domain ID is valid; otherwise + * returns an error. + */ +static ssize_t unassign_control_domain_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + int ret; + unsigned long domid; + struct mdev_device *mdev = mdev_from_dev(dev); + struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); + unsigned long max_domid = matrix_mdev->matrix.adm_max; + + ret = kstrtoul(buf, 0, &domid); + if (ret) + return ret; + if (domid > max_domid) + return -EINVAL; + + mutex_lock(&matrix_dev.lock); + clear_bit_inv(domid, matrix_mdev->matrix.adm); + mutex_unlock(&matrix_dev.lock); + + return count; +} +DEVICE_ATTR_WO(unassign_control_domain); + +static ssize_t control_domains_show(struct device *dev, + struct device_attribute *dev_attr, + char *buf) +{ + unsigned long id; + int nchars = 0; + int n; + char *bufpos = buf; + struct mdev_device *mdev = mdev_from_dev(dev); + struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); + unsigned long max_domid = matrix_mdev->matrix.adm_max; + + mutex_lock(&matrix_dev.lock); + for_each_set_bit_inv(id, matrix_mdev->matrix.adm, max_domid + 1) { + n = sprintf(bufpos, "%04lx\n", id); + bufpos += n; + nchars += n; + } + mutex_unlock(&matrix_dev.lock); + + return nchars; +} +DEVICE_ATTR_RO(control_domains); + static struct attribute *vfio_ap_mdev_attrs[] = { &dev_attr_assign_adapter.attr, &dev_attr_unassign_adapter.attr, &dev_attr_assign_domain.attr, &dev_attr_unassign_domain.attr, + &dev_attr_assign_control_domain.attr, + &dev_attr_unassign_control_domain.attr, + &dev_attr_control_domains.attr, NULL, };