Thanks! Was hoping you'd respond. So essentially to do the disk encryption stuff documented here https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lxdc/lxdc_linuxonz.html one has to dedicate to the guest.
If I can put 16 cards on a z15, I'm essentially limited to 8 guests per LPAR with the ability to do this. (need redundancy so two per guest). Correct ? There's not a way to dedicate, put master key on, then make it apvirt after that, correct? Marcy -----Original Message----- From: Linux on 390 Port <[email protected]> On Behalf Of Reinhard Buendgen Sent: Monday, January 13, 2020 7:19 AM To: [email protected] Subject: Re: [LINUX-390] Pervasive disk encryption questions Hi, crypto adapter domains defined for z/VM guests with APVIRT are restricted to perform clear key crypto operations (possibly including random number generations). Regard less whether the backing adapters are in accelerator mode or in CCA mode (AP-virt does not support adapters in EP11 mode). And if there are multiple backing adapters of different modes z/VM gives priority to accelerator mode when choosing the type of the shared virtual adapter. When you want to use secure key crypto you must define your crypto adapter domain in the guest as dedicated adapter (APDED for z/VM guests, for KVM guests currently only dedicated adapter domains are supported). Dedicated adapter domains can be of any type: accelerator, CCA or EP11. Only the CCA and EP11 types provide support for clear key crypto. To set/manage the master key of a dedicated CCA adapter domain assigned to a guest there are multiple options — connect the TKE to the catcher.exe daemon (part of the CCA host package) running on the Linux system and use the TKE to mange the master key of the adapter domain belonging to the Linux guest (option recommended for production use) — use the panel.exe tool (part of the CCA host package) on the Linux guest to set/manage the master key of the adapter domain belonging to the Linux guest (this option is not recommended for production use, due to some security limitations -- I like this option ) — use a z/OS System on the same CEC (or other Linux System) that has an appropriate control domain setting. Using the z/OS system can go via ICSF functions (which I guess are similar in function and security to what the panel.exe tool provides) or a TKE connected to the z/OS system. — use another Linux system on the same CEC that has an appropriate control domain setting and do the management either vie panel.exe or TKE (again TKE being recommended for production use). There is no need for a special system to set master keys. Each system can manage its own master keys. But if you choose to do so, say because you want to use ICSF or panel.exe from a particularly secured system then all you need is a system that has an arbitrary usage domain and control domains configured to the domains you want to manage. Unfortunately control domains cannot be freely configured for z/VM guests. (z/VM sets the control domain to be equal to the usage domain). So this option works only for LPARs and KVM guests. For z/VM guests you may have to switch the adapter domains form the key mangement guest to the actual working guests. Reinhard ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
