1. 20 2月, 2019 1 次提交
    • H
      s390/zcrypt: fix specification exception on z196 during ap probe · 88e1e66a
      Harald Freudenberger 提交于
      commit 8f9aca0c45322a807a343fc32f95f2500f83b9ae upstream.
      
      The older machines don't have the QCI instruction available.
      With support for up to 256 crypto cards the probing of each
      card has been extended to check card ids from 0 up to 255.
      For machines with QCI support there is a filter limiting the
      range of probed cards. The older machines (z196 and older)
      don't have this filter and so since support for 256 cards is
      in the driver all cards are probed. However, these machines
      also require to have the card id fit into 6 bits. Exceeding
      this limit results in a specification exception which happens
      on every kernel startup even when there is no crypto configured
      and used at all.
      
      This fix limits the range of probed crypto cards to 64 if
      there is no QCI instruction available to obey to the older
      ap architecture and so fixes the specification exceptions
      on z196 machines.
      
      Cc: stable@vger.kernel.org # v4.17+
      Fixes: af4a7227 ("s390/zcrypt: Support up to 256 crypto adapters.")
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88e1e66a
  2. 12 9月, 2018 1 次提交
  3. 21 8月, 2018 1 次提交
    • H
      s390/zcrypt: hex string mask improvements for apmask and aqmask. · 3d8f60d3
      Harald Freudenberger 提交于
      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: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      3d8f60d3
  4. 20 8月, 2018 2 次提交
    • H
      s390/zcrypt: AP bus support for alternate driver(s) · 7e0bdbe5
      Harald Freudenberger 提交于
      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: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      7e0bdbe5
    • H
      s390/zcrypt: code beautify · ac2b96f3
      Harald Freudenberger 提交于
      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: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      ac2b96f3
  5. 16 8月, 2018 1 次提交
  6. 19 7月, 2018 1 次提交
  7. 25 6月, 2018 1 次提交
  8. 10 4月, 2018 3 次提交
  9. 24 11月, 2017 2 次提交
    • G
      s390: crypto: Remove redundant license text · 0b622e60
      Greg Kroah-Hartman 提交于
      Now that the SPDX tag is in all drivers/s390/crypto/ files, that
      identifies the license in a specific and legally-defined manner.  So the
      extra GPL text wording can be removed as it is no longer needed at all.
      
      This is done on a quest to remove the 700+ different ways that files in
      the kernel describe the GPL license text.  And there's unneeded stuff
      like the address (sometimes incorrect) for the FSF which is never
      needed.
      
      No copyright headers or other non-license-description text was removed.
      
      Cc: Harald Freudenberger <freude@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      0b622e60
    • G
      s390: crypto: add SPDX identifiers to the remaining files · 812141a9
      Greg Kroah-Hartman 提交于
      It's good to have SPDX identifiers in all files to make it easier to
      audit the kernel tree for correct licenses.
      
      Update the drivers/s390/crypto/ files with the correct SPDX license
      identifier based on the license text in the file itself.  The SPDX
      identifier is a legally binding shorthand, which can be used instead of
      the full boiler plate text.
      
      This work is based on a script and data from Thomas Gleixner, Philippe
      Ombredanne, and Kate Stewart.
      
      Cc: Harald Freudenberger <freude@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      812141a9
  10. 14 11月, 2017 1 次提交
  11. 09 11月, 2017 1 次提交
  12. 23 10月, 2017 1 次提交
    • H
      s390/zcrypt: Introduce QACT support for AP bus devices. · 9a564108
      Harald Freudenberger 提交于
      This patch introduces a new ap_qact() function which
      exploits the PQAP(QACT) subfunction. QACT is a new
      interface to Query the Ap Compatilibity Type based
      on a given AP qid, type, mode and version.
      
      Based on this new function the AP bus scan code is
      slightly reworked to use this new interface for
      querying the compatible type for each new AP queue
      device detected. So new and unknown devices can
      get automatically mapped to a compatible type and
      handled without the need for toleration patches
      for every new hardware.
      
      The currently highest known hardware is CEX6S.
      With this patch a possible successor can get
      queried for a combatible type known by the device
      driver without the need for an toleration patch.
      Signed-off-by: NHarald Freudenberger <freude@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      9a564108
  13. 06 9月, 2017 2 次提交
  14. 12 6月, 2017 1 次提交
  15. 02 6月, 2017 1 次提交
    • H
      s390/zcrypt: Fix blocking queue device after unbind/bind. · e3850508
      Harald Freudenberger 提交于
      When the association between a queue device and the
      driver is released via unbind and later re-associated
      the queue device was not operational any more. Reason
      was a wrong administration of the card/queue lists
      within the ap device driver.
      
      This patch introduces revised card/queue list handling
      within the ap device driver: when an ap device is
      detected it is initial not added to the card/queue list
      any more. With driver probe the card device is added to
      the card list/the queue device is added to the queue list
      within a card. With driver remove the device is removed
      from the card/queue list. Additionally there are some
      situations within the ap device live where the lists
      need update upon card/queue device release (for example
      device hot unplug or suspend/resume).
      Signed-off-by: NHarald Freudenberger <freude@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e3850508
  16. 23 2月, 2017 1 次提交
  17. 20 2月, 2017 2 次提交
  18. 26 12月, 2016 1 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      Thomas Gleixner 提交于
      ktime_set(S,N) was required for the timespec storage type and is still
      useful for situations where a Seconds and Nanoseconds part of a time value
      needs to be converted. For anything where the Seconds argument is 0, this
      is pointless and can be replaced with a simple assignment.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
  19. 14 12月, 2016 8 次提交
  20. 02 12月, 2016 1 次提交
  21. 31 7月, 2016 2 次提交
  22. 28 6月, 2016 1 次提交
  23. 10 5月, 2016 1 次提交
  24. 27 11月, 2015 1 次提交
  25. 11 11月, 2015 1 次提交
    • S
      s390/zcrypt: Fix kernel crash on systems without AP bus support · e387753c
      Sascha Silbe 提交于
      On systems without AP bus (e.g. KVM) the kernel crashes during init
      calls when zcrypt is built-in:
      
      kernel BUG at drivers/base/driver.c:153!
      illegal operation: 0001 ilc:1 [#1] SMP
      Modules linked in:
      CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0+ #221
      task: 0000000010a40000 ti: 0000000010a48000 task.ti:0000000010a48000
      Krnl PSW : 0704c00180000000 0000000000592bd6(driver_register+0x106/0x140)
                 R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
                 0000000000000012 0000000000000000 0000000000c45328 0000000000c44e30
                 00000000009ef63c 000000000067f598 0000000000cf3c58 0000000000000000
                 000000000000007b 0000000000cb1030 0000000000000002 0000000000000000
                 0000000000ca8580 0000000010306700 00000000001001d8 0000000010a4bd88
      Krnl Code: 0000000000592bc6: f0b00004ebcf	srp 4(12,%r0),3023(%r14),0
                 0000000000592bcc: f0a0000407f4       srp     4(11,%r0),2036,0
                #0000000000592bd2: a7f40001           brc     15,592bd4
                >0000000000592bd6: e330d0000004       lg      %r3,0(%r13)
                 0000000000592bdc: c0200021edfd       larl    %r2,9d07d6
                 0000000000592be2: c0e500126d8f       brasl   %r14,7e0700
                 0000000000592be8: e330d0080004       lg      %r3,8(%r13)
                 0000000000592bee: a7f4ffab           brc     15,592b44
      Call Trace:
      ([<00000000001001c8>] do_one_initcall+0x90/0x1d0)
       [<0000000000c6dd34>] kernel_init_freeable+0x1e4/0x2a0
       [<00000000007db53a>] kernel_init+0x2a/0x120
       [<00000000007e8ece>] kernel_thread_starter+0x6/0xc
       [<00000000007e8ec8>] kernel_thread_starter+0x0/0xc
      Last Breaking-Event-Address:
       [<0000000000592bd2>] driver_register+0x102/0x140
      
      When zcrypt is built as a module, the module loader ensures that the
      driver modules cannot be loaded if the AP bus module returns an error
      during initialisation. But if zcrypt and the driver are built-in, the
      driver is getting initialised even if the AP bus initialisation
      failed. The driver invokes ap_driver_register() during initialisation,
      which then causes operations on uninitialised data structures to be
      performed.
      
      Explicitly protect ap_driver_register() by introducing an
      "initialised" flag that gets set iff the AP bus initialisation was
      successful. When the AP bus initialisation failed,
      ap_driver_register() will error out with -ENODEV, causing the driver
      initialisation to fail as well.
      
      Test results:
      1. Inside KVM (no AP bus), zcrypt built-in
      
         Boots. /sys/bus/ap not present (expected).
      
      2. Inside KVM (no AP bus), zcrypt as module
      
         Boots. Loading zcrypt_cex4 fails because loading ap_bus fails
         (expected).
      
      3. On LPAR with CEX5, zcrypt built-in
      
         Boots. /sys/bus/ap/devices/card* present but .../card*/type missing
         (i.e. zcrypt_device_register() fails, unrelated issue).
      
      4. On LPAR with CEX5, zcrypt as module
      
         Boots. Loading zcrypt_cex4 successful,
         /sys/bus/ap/devices/card*/type present. No further testing
         (user-space functionality) was done.
      Signed-off-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e387753c
  26. 14 10月, 2015 1 次提交