** Description changed:
+ == SRU Justification ==
+
+ APQN tags in the zcrypt device driver are required to support
+ deterministic driver binding
+
+ With the introduction of KVM hw crypto virtualization (on s390x) the driver
bound to an AP queue device is no longer unique determined.
+ Therefore a deterministic hot plugging semantics of AP queues that may be
bound to multiple drivers is needed.
+ With the three listed commits here it will be possible to configure an AP
queue (APQN) as being bound to a particular driver even if the associate hw
gets intermittently lost and reconnected.
+
+ == Fix ==
+
+ ac2b96f351d7d222 ("s390/zcrypt: code beautify")
+ 7e0bdbe5c21cb831 ("s390/zcrypt: AP bus support for alternate driver(s)")
+ 3d8f60d38e249f98 ("s390/zcrypt: hex string mask improvements for apmask and
aqmask")
+
+ == Patch ==
+
+ Git-commit: ac2b96f351d7d222
+
https://github.com/torvalds/linux/commit/ac2b96f351d7d222c46e524feca03005f3fa8d75
+ Author: Harald Freudenberger <[email protected]>
+ Date: Fri Aug 17 12:36:01 2018 +0200
+ s390/zcrypt: code beautify
+ Code beautify by following most of the checkpatch suggestions:
+ - SPDX license identifier line complains by checkpatch
+ - missing space or newline complains by checkpatch
+ - octal numbers for permssions complains by checkpatch
+ - renaming of static sysfs functions complains by checkpatch
+ - fix of block comment complains by checkpatch
+ - fix printf like calls where function name instead of %s __func__
+ was used
+ - __packed instead of __attribute__((packed))
+ - init to zero for static variables removed
+ - use of DEVICE_ATTR_RO and DEVICE_ATTR_RW macros
+
+ No functional code changes or API changes!
+
+ Signed-off-by: Harald Freudenberger <[email protected]>
+ Signed-off-by: Martin Schwidefsky <[email protected]>
+
+ ===
+
+ Git-commit 7e0bdbe5c21cb831
+
https://github.com/torvalds/linux/commit/7e0bdbe5c21cb8316a694e46ad5aad339f6894a6
+ Author: Harald Freudenberger <[email protected]>
+ Date: Fri Jul 20 08:36:53 2018 +0200
+ s390/zcrypt: AP bus support for alternate driver(s)
+ The current AP bus, AP devices and AP device drivers implementation
+ uses a clearly defined mapping for binding AP devices to AP device
+ drivers. So for example a CEX6C queue will always be bound to the
+ cex4queue device driver.
+
+ The Linux Device Driver model has no sensitivity for more than one
+ device driver eligible for one device type. If there exist more than
+ one drivers matching to the device type, simple all drivers are tried
+ consecutively. There is no way to determine and influence the probing
+ order of the drivers.
+
+ With KVM there is a need to provide additional device drivers matching
+ to the very same type of AP devices. With a simple implementation the
+ KVM drivers run in competition to the regular drivers. Whichever
+ 'wins' a device depends on build order and implementation details
+ within the common Linux Device Driver Model and is not
+ deterministic. However, a userspace process could figure out which
+ device should be bound to which driver and sort out the correct
+ binding by manipulating attributes in the sysfs.
+
+ If for security reasons a AP device must not get bound to the 'wrong'
+ device driver the sorting out has to be done within the Linux kernel
+ by the AP bus code. This patch modifies the behavior of the AP bus
+ for probing drivers for devices in a way that two sets of drivers are
+ usable. Two new bitmasks 'apmask' and 'aqmask' are used to mark a
+ subset of the APQN range for 'usable by the ap bus and the default
+ drivers' or 'not usable by the default drivers and thus available for
+ alternate drivers like vfio-xxx'. So an APQN which is addressed by
+ this masking only the default drivers will be probed. In contrary an
+ APQN which is not addressed by the masks will never be probed and
+ bound to default drivers but onny to alternate drivers.
+
+ Eventually the two masks give a way to divide the range of APQNs into
+ two pools: one pool of APQNs used by the AP bus and the default
+ drivers and thus via zcrypt drivers available to the userspace of the
+ system. And another pool where no zcrypt drivers are bound to and
+ which can be used by alternate drivers (like vfio-xxx) for their
+ needs. This division is hot-plug save and makes sure a APQN assigned
+ to an alternate driver is at no time somehow exploitable by the wrong
+ party.
+
+ The two masks are located in sysfs at /sys/bus/ap/apmask and
+ /sys/bus/ap/aqmask. The mask syntax is exactly the same as the
+ already existing mask attributes in the /sys/bus/ap directory (for
+ example ap_usage_domain_mask and ap_control_domain_mask).
+
+ By default all APQNs belong to the ap bus and the default drivers:
+
+ cat /sys/bus/ap/apmask
+ 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ cat /sys/bus/ap/aqmask
+ 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+
+ The masks can be changed at boot time with the kernel command line
+ like this:
+
+ ... ap.apmask=0xffff ap.aqmask=0x40
+
+ This would give these two pools:
+
+ default drivers pool: adapter 0 - 15, domain 1
+ alternate drivers pool: adapter 0 - 15, all but domain 1
+ adapter 16-255, all domains
+
+ The sysfs attributes for this two masks are writeable and an
+ administrator is able to reconfigure the assignements on the fly by
+ writing new mask values into. With changing the mask(s) a revision of
+ the existing queue to driver bindings is done. So all APQNs which are
+ bound to the 'wrong' driver are reprobed via kernel function
+ device_reprobe() and thus the new correct driver will be assigned with
+ respect of the changed apmask and aqmask bits.
+
+ The mask values are bitmaps in big endian order starting with bit 0.
+ So adapter number 0 is the leftmost bit, mask is 0x8000... The sysfs
+ attributes accept 2 different formats:
+ - Absolute hex string starting with 0x like "0x12345678" does set
+ the mask starting from left to right. If the given string is shorter
+ than the mask it is padded with 0s on the right. If the string is
+ longer than the mask an error comes back (EINVAL).
+ - '+' or '-' followed by a numerical value. Valid examples are "+1",
+ "-13", "+0x41", "-0xff" and even "+0" and "-0". Only the addressed
+ bit in the mask is switched on ('+') or off ('-').
+
+ This patch will also be the base for an upcoming extension to the
+ zcrypt drivers to be able to provide additional zcrypt device nodes
+ with filtering based on ap and aq masks.
+
+ Signed-off-by: Harald Freudenberger <[email protected]>
+ Signed-off-by: Martin Schwidefsky <[email protected]>
+
+ ===
+
+ Git-commit 3d8f60d38e249f98
+
https://github.com/torvalds/linux/commit/3d8f60d38e249f989a7fca9c2370c31c3d5487e1
+ Author: Harald Freudenberger <[email protected]>
+ Date: Mon Aug 20 15:27:45 2018 +0200
+ s390/zcrypt: hex string mask improvements for apmask and aqmask
+ The sysfs attributes /sys/bus/ap/apmask and /sys/bus/ap/aqmask
+ and the kernel command line arguments ap.apm and ap.aqm get
+ an improvement of the value parsing with this patch:
+
+ The mask values are bitmaps in big endian order starting with bit 0.
+ So adapter number 0 is the leftmost bit, mask is 0x8000... The sysfs
+ attributes and the kernel command line accept 2 different formats:
+ - Absolute hex string starting with 0x like "0x12345678" does set
+ the mask starting from left to right. If the given string is shorter
+ than the mask it is padded with 0s on the right. If the string is
+ longer than the mask an error comes back (EINVAL).
+ - Relative format - a concatenation (done with ',') of the terms
+ +<bitnr>[-<bitnr>] or -<bitnr>[-<bitnr>]. <bitnr> may be any
+ valid number (hex, decimal or octal) in the range 0...255.
+ Here are some examples:
+ "+0-15,+32,-128,-0xFF"
+ "-0-255,+1-16,+0x128"
+
+ Signed-off-by: Harald Freudenberger <[email protected]>
+ Signed-off-by: Martin Schwidefsky <[email protected]>
+
+ == Regression Potential ==
+
+ Mid to low. because:
+
+ - There are quite some changes, but everything is limited to s390/zcrypt,
means:
+ arch/s390/include/uapi/asm/*
+ and
+ drivers/s390/crypto/*
+ - So everything is s390x specific.
+ - And larger parts of the changes are beautifications.
+ - The code is already successfully test, integrated and running in cosmic.
+
+ == Test Case ==
+
+ On an LPAR that has access to an CryptoExpress card,
+
+ execute the 'lszcrypt --verbose'
+ and check availability of:
+ /sys/bus/ap/apmask
+
+ General test and verification was already done by IBM.
+ Please notice that the code already landed in cosmic.
+ __________
+
With the introduction of KVM crypto virtualization the driver bound to an AP
queue device is no longer unique determined.
This feature provides a deterministic hot plugging semantics of AP queues
that may be bound to multiple drivers.
In particular it enables to configure an AP queue (APQN) as being bound to a
particular driver even if the associate HW gets intermittently lost and
reconnected.
This function has to be applied to kernel 4.15 for Ubuntu 18.04,
Git Commit information available here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784331
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1799184
Title:
[18.04 FEAT] zcrypt DD: introduce APQN tags to support deterministic
driver binding
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1799184/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
