linux-kernel - Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180822114250.59a250aa.cohuck@redhat.com>
Date:   Wed, 22 Aug 2018 11:42:50 +0200
From:   Cornelia Huck <cohuck@...hat.com>
To:     Halil Pasic <pasic@...ux.ibm.com>
Cc:     Tony Krowiak <akrowiak@...ux.ibm.com>,
        Tony Krowiak <akrowiak@...ux.vnet.ibm.com>,
        linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, freude@...ibm.com, schwidefsky@...ibm.com,
        heiko.carstens@...ibm.com, borntraeger@...ibm.com,
        kwankhede@...dia.com, bjsdjshi@...ux.vnet.ibm.com,
        pbonzini@...hat.com, alex.williamson@...hat.com,
        pmorel@...ux.vnet.ibm.com, alifm@...ux.vnet.ibm.com,
        mjrosato@...ux.vnet.ibm.com, jjherne@...ux.vnet.ibm.com,
        thuth@...hat.com, pasic@...ux.vnet.ibm.com, berrange@...hat.com,
        fiuczy@...ux.vnet.ibm.com, buendgen@...ibm.com,
        frankja@...ux.ibm.com
Subject: Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure
 control domains

On Wed, 22 Aug 2018 01:18:20 +0200
Halil Pasic <pasic@...ux.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?)