• H
    s390/zcrypt: multiple zcrypt device nodes support · 00fab235
    Harald Freudenberger 提交于
    This patch is an extension to the zcrypt device driver to provide,
    support and maintain multiple zcrypt device nodes. The individual
    zcrypt device nodes can be restricted in terms of crypto cards,
    domains and available ioctls. Such a device node can be used as a
    base for container solutions like docker to control and restrict
    the access to crypto resources.
    
    The handling is done with a new sysfs subdir /sys/class/zcrypt.
    Echoing a name (or an empty sting) into the attribute "create" creates
    a new zcrypt device node. In /sys/class/zcrypt a new link will appear
    which points to the sysfs device tree of this new device. The
    attribute files "ioctlmask", "apmask" and "aqmask" in this directory
    are used to customize this new zcrypt device node instance. Finally
    the zcrypt device node can be destroyed by echoing the name into
    /sys/class/zcrypt/destroy. The internal structs holding the device
    info are reference counted - so a destroy will not hard remove a
    device but only marks it as removable when the reference counter drops
    to zero.
    
    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).
    * 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"
        "+1,+2,+3,+4,-5,-7-10"
    
    A simple usage examples:
    
      # create new zcrypt device 'my_zcrypt':
      echo "my_zcrypt" >/sys/class/zcrypt/create
      # go into the device dir of this new device
      echo "my_zcrypt" >create
      cd my_zcrypt/
      ls -l
      total 0
      -rw-r--r-- 1 root root 4096 Jul 20 15:23 apmask
      -rw-r--r-- 1 root root 4096 Jul 20 15:23 aqmask
      -r--r--r-- 1 root root 4096 Jul 20 15:23 dev
      -rw-r--r-- 1 root root 4096 Jul 20 15:23 ioctlmask
      lrwxrwxrwx 1 root root    0 Jul 20 15:23 subsystem -> ../../../../class/zcrypt
      ...
      # customize this zcrypt node clone
      # enable only adapter 0 and 2
      echo "0xa0" >apmask
      # enable only domain 6
      echo "+6" >aqmask
      # enable all 256 ioctls
      echo "+0-255" >ioctls
      # now the /dev/my_zcrypt may be used
      # finally destroy it
      echo "my_zcrypt" >/sys/class/zcrypt/destroy
    
    Please note that a very similar 'filtering behavior' also applies to
    the parent z90crypt device. The two mask attributes apmask and aqmask
    in /sys/bus/ap act the very same for the z90crypt device node. However
    the implementation here is totally different as the ap bus acts on
    bind/unbind of queue devices and associated drivers but the effect is
    still the same. So there are two filters active for each additional
    zcrypt device node: The adapter/domain needs to be enabled on the ap
    bus level and it needs to be active on the zcrypt device node level.
    Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
    Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
    00fab235
ap_bus.c 39.0 KB