1. 05 Sep, 2019 2 commits
  2. 03 Sep, 2019 2 commits
  3. 29 Aug, 2019 7 commits
  4. 26 Aug, 2019 7 commits
  5. 23 Aug, 2019 1 commit
    • Cornelia Huck's avatar
      vfio-ccw: add some logging · 60e05d1c
      Cornelia Huck authored
      Usually, the common I/O layer logs various things into the s390
      cio debug feature, which has been very helpful in the past when
      looking at crash dumps. As vfio-ccw devices unbind from the
      standard I/O subchannel driver, we lose some information there.
      
      Let's introduce some vfio-ccw debug features and log some things
      there. (Unfortunately we cannot reuse the cio debug feature from
      a module.)
      
      Message-Id: <20190816151505.9853-2-cohuck@redhat.com>
      Reviewed-by: default avatarEric Farman <farman@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      60e05d1c
  6. 21 Aug, 2019 20 commits
    • Harald Freudenberger's avatar
      s390/paes: Prepare paes functions for large key blobs · 416f79c2
      Harald Freudenberger authored
      The context used to store the key blob used a fixed 80 bytes
      buffer. And all the set_key functions did not even check the given key
      size. With CCA variable length AES cipher keys there come key blobs
      with about 136 bytes and maybe in the future there will arise the need
      to store even bigger key blobs.
      
      This patch reworks the paes set_key functions and the context
      buffers to work with small key blobs (<= 128 bytes) directly in the
      context buffer and larger blobs by allocating additional memory and
      storing the pointer in the context buffer. If there has been memory
      allocated for storing a key blob, it also needs to be freed on release
      of the tfm. So all the paes ciphers now have a init and exit function
      implemented for this job.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarIngo Franzki <ifranzki@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      416f79c2
    • Harald Freudenberger's avatar
      s390/pkey: add CCA AES cipher key support · f2bbc96e
      Harald Freudenberger authored
      Introduce new ioctls and structs to be used with these new ioctls
      which are able to handle CCA AES secure keys and CCA AES cipher keys:
      
      PKEY_GENSECK2: Generate secure key, version 2.
        Generate either a CCA AES secure key or a CCA AES cipher key.
      
      PKEY_CLR2SECK2: Generate secure key from clear key value, version 2.
        Construct a CCA AES secure key or CCA AES cipher key from a given
        clear key value.
      
      PKEY_VERIFYKEY2: Verify the given secure key, version 2.
        Check for correct key type. If cardnr and domain are given, also
        check if this apqn is able to handle this type of key. If cardnr and
        domain are 0xFFFF, on return these values are filled with an apqn
        able to handle this key. The function also checks for the master key
        verification patterns of the key matching to the current or
        alternate mkvp of the apqn. CCA AES cipher keys are also checked
        for CPACF export allowed (CPRTCPAC flag). Currently CCA AES secure
        keys and CCA AES cipher keys are supported (may get extended in the
        future).
      
      PKEY_KBLOB2PROTK2: Transform a key blob (of any type) into
        a protected key, version 2. Difference to version 1 is only that
        this new ioctl has additional parameters to provide a list of
        apqns to be used for the transformation.
      
      PKEY_APQNS4K: Generate a list of APQNs based on the key blob given.
        Is able to find out which type of secure key is given (CCA AES
        secure key or CCA AES cipher key) and tries to find all matching
        crypto cards based on the MKVP and maybe other criterias (like CCA
        AES cipher keys need a CEX6C or higher). The list of APQNs is
        further filtered by the key's mkvp which needs to match to either
        the current mkvp or the alternate mkvp (which is the old mkvp on CCA
        adapters) of the apqns. The flags argument may be used to limit the
        matching apqns. If the PKEY_FLAGS_MATCH_CUR_MKVP is given, only the
        current mkvp of each apqn is compared. Likewise with the
        PKEY_FLAGS_MATCH_ALT_MKVP. If both are given it is assumed to return
        apqns where either the current or the alternate mkvp matches. If no
        matching APQN is found, the ioctl returns with 0 but the
        apqn_entries value is 0.
      
      PKEY_APQNS4KT: Generate a list of APQNs based on the key type given.
        Build a list of APQNs based on the given key type and maybe further
        restrict the list by given master key verification patterns.
        For different key types there may be different ways to match the
        master key verification patterns. For CCA keys (CCA data key and CCA
        cipher key) the first 8 bytes of cur_mkvp refer to the current mkvp
        value of the apqn and the first 8 bytes of the alt_mkvp refer to the
        old mkvp. The flags argument controls if the apqns current and/or
        alternate mkvp should match. If the PKEY_FLAGS_MATCH_CUR_MKVP is
        given, only the current mkvp of each apqn is compared. Likewise with
        the PKEY_FLAGS_MATCH_ALT_MKVP. If both are given, it is assumed to
        return apqns where either the current or the alternate mkvp
        matches. If no matching APQN is found, the ioctl returns with 0 but
        the apqn_entries value is 0.
      
      These new ioctls are now prepared for another new type of secure key
      blob which may come in the future. They all use a pointer to the key
      blob and a key blob length information instead of some hardcoded byte
      array. They all use the new enums pkey_key_type, pkey_key_size and
      pkey_key_info for getting/setting key type, key size and additional
      info about the key. All but the PKEY_VERIFY2 ioctl now work based on a
      list of apqns. This list is walked through trying to perform the
      operation on exactly this apqn without any further checking (like card
      type or online state). If the apqn fails, simple the next one in the
      list is tried until success (return 0) or the end of the list is
      reached (return -1 with errno ENODEV). All apqns in the list need to
      be exact apqns (0xFFFF as any card or domain is not allowed). There
      are two new ioctls which can be used to build a list of apqns based on
      a key or key type and maybe restricted by match to a current or
      alternate master key verifcation pattern.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarIngo Franzki <ifranzki@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      f2bbc96e
    • Harald Freudenberger's avatar
      s390/zcrypt: Add low level functions for CCA AES cipher keys · 4bc123b1
      Harald Freudenberger authored
      This patch adds low level functions, structs and defines to support
      CCA AES cipher keys:
      - struct cipherkeytoken can be used for an inside view of the CCA AES
        cipher key token blob.
      - function cca_cipher2protkey() derives an CPACF protected key from an
        CCA AES cipher key.
      - function cca_gencipherkey() generates an CCA AES cipher key with
        random value.
      - function cca_findcard2() constructs a list of apqns based on input
        constrains like min hardware type, mkvp values.
      - cca_check_secaescipherkey() does a check on the given CCA AES cipher
        key blob.
      - cca_clr2cipherkey() generates an CCA AES cipher key from a given
        clear key value.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarIngo Franzki <ifranzki@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      4bc123b1
    • Harald Freudenberger's avatar
      s390/zcrypt: extend cca_findcard function and helper · 4da57a2f
      Harald Freudenberger authored
      Rework and extension of the cca_findcard function to be prepared for
      other types of secure key blobs. Split the function and extract an
      internal function which has no awareness of key blobs any
      more. Improve this function and the helper code around to be able to
      check for a minimal crypto card hardware level (Background: the newer
      AES cipher keys need to match to the master key verification pattern
      and need to have a crypto card CEX6 or higher).
      
      No API change, neither for the in-kernel API nor the ioctl interface.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarIngo Franzki <ifranzki@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      4da57a2f
    • Harald Freudenberger's avatar
      s390/pkey: pkey cleanup: narrow in-kernel API, fix some variable types · 183cb469
      Harald Freudenberger authored
      There are a lot of pkey functions exported as in-kernel callable
      API functions but not used at all. This patch narrows down the
      pkey in-kernel API to what is currently only used and exploited.
      
      Within the kernel just use u32 without any leading __u32. Also
      functions declared in a header file in arch/s390/include/asm
      don't need a comment 'In-kernel API', this is by definition,
      otherwise the header file would be in arch/s390/include/uapi/asm.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarIngo Franzki <ifranzki@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      183cb469
    • Vasily Gorbik's avatar
      s390/startup: round down "mem" option to page boundary · 22a33c7e
      Vasily Gorbik authored
      Make a usable value out of "mem" option once and for all. Kasan memory
      allocator just takes memory_end or online memory size as allocation
      base. If memory_end is not aligned paging structures allocated in kasan
      end up unaligned as well. So this change fixes potential kasan crash
      as well.
      
      Fixes: 78333d1f ("s390/kasan: add support for mem= kernel parameter")
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      22a33c7e
    • Vasily Gorbik's avatar
      s390/startup: adjust _sdma and _edma to page boundaries · 80ef517b
      Vasily Gorbik authored
      Move .dma.text section alignment out of section description, otherwise
      zeros used to align the section are included in the section itself (and
      section is not really aligned by itself).
      $ objdump -h arch/s390/boot/compressed/vmlinux
        5 .dma.text     00001e38  000000000001b1c8  000000000001b1c8  0001c1c8  2**2
                        CONTENTS, ALLOC, LOAD, READONLY, CODE
        6 .dma.ex_table 00000018  000000000001d000  000000000001d000  0001e000  2**2
                        CONTENTS, ALLOC, LOAD, READONLY, DATA
        7 .dma.data     00000240  000000000001d080  000000000001d080  0001e080  2**7
                        CONTENTS, ALLOC, LOAD, DATA
      $ cat /sys/kernel/debug/memblock/reserved
         0: 0x0000000000000000..0x0000000000011fff
         1: 0x000000000001b1c8..0x000000000001d2bf
      ...
      
      Also add alignment before _edma linker symbol definition, so that entire
      .dma* region is rounded up to page boundaries.
      $ objdump -h arch/s390/boot/compressed/vmlinux
        5 .dma.text     00001000  000000000001c000  000000000001c000  0001d000  2**2
                        CONTENTS, ALLOC, LOAD, READONLY, CODE
        6 .dma.ex_table 00000018  000000000001d000  000000000001d000  0001e000  2**2
                        CONTENTS, ALLOC, LOAD, READONLY, DATA
        7 .dma.data     00000240  000000000001d080  000000000001d080  0001e080  2**7
                        CONTENTS, ALLOC, LOAD, DATA
      $ cat /sys/kernel/debug/memblock/reserved
         0: 0x0000000000000000..0x0000000000011fff
         1: 0x000000000001c000..0x000000000001dfff
      ...
      $ cat /sys/kernel/debug/kernel_page_tables
      ---[ Identity Mapping ]---
      0x0000000000000000-0x000000000001c000       112K PTE RW NX
      0x000000000001c000-0x000000000001d000         4K PTE RO X
      0x000000000001d000-0x0000000000100000       908K PTE RW NX
      ...
      Reviewed-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      80ef517b
    • Vasily Gorbik's avatar
      s390/stacktrace: use common arch_stack_walk infrastructure · e991e5bb
      Vasily Gorbik authored
      Use common arch_stack_walk infrastructure to avoid duplicated code and
      avoid taking care of the stack storage and filtering.
      
      Common code also uses try_get_task_stack/put_task_stack when needed which
      have been missing in our code, which also solves potential problem for us.
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      e991e5bb
    • Vasily Gorbik's avatar
      s390/kasan: avoid report in get_wchan · 2c7fa8a1
      Vasily Gorbik authored
      Reading other running task's stack can be a dangerous endeavor. Kasan
      stack memory access instrumentation includes special prologue and epilogue
      to mark/remove red zones in shadow memory between stack variables. For
      that reason there is always a race between a task reading value in other
      task's stack and that other task returning from a function and entering
      another one generating different red zones pattern.
      
      To avoid kasan reports simply perform uninstrumented memory reads.
      Acked-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      2c7fa8a1
    • Vasily Gorbik's avatar
      s390/process: avoid potential reading of freed stack · 8769f610
      Vasily Gorbik authored
      With THREAD_INFO_IN_TASK (which is selected on s390) task's stack usage
      is refcounted and should always be protected by get/put when touching
      other task's stack to avoid race conditions with task's destruction code.
      
      Fixes: d5c352cd ("s390: move thread_info into task_struct")
      Cc: stable@vger.kernel.org # v4.10+
      Acked-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      8769f610
    • Vasily Gorbik's avatar
      s390/kasan: provide uninstrumented __strlen · f45f7b5b
      Vasily Gorbik authored
      s390 kasan code uses sclp_early_printk to report initialization
      failures. The code doing that should not be instrumented, because kasan
      shadow memory has not been set up yet. Even though sclp_early_core.c is
      compiled with instrumentation disabled it uses strlen function, which
      is instrumented and would produce shadow memory access if used. To
      avoid that, introduce uninstrumented __strlen function to be used
      instead.
      
      Before commit 7e0d92f0 ("s390/kasan: improve string/memory functions
      checks") few string functions (including strlen) were escaping kasan
      instrumentation due to usage of platform specific versions which are
      implemented in inline assembly.
      
      Fixes: 7e0d92f0 ("s390/kasan: improve string/memory functions checks")
      Acked-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      f45f7b5b
    • Vasily Gorbik's avatar
      s390: clean .bss before running uncompressed kernel · 2e83e0eb
      Vasily Gorbik authored
      Clean uncompressed kernel .bss section in the startup code before
      the uncompressed kernel is executed. At this point of time initrd and
      certificates have been already rescued. Uncompressed kernel .bss size
      is known from vmlinux_info. It is also taken into consideration during
      uncompressed kernel positioning by kaslr (so it is safe to clean it).
      
      With that uncompressed kernel is starting with .bss section zeroed and
      no .bss section usage restrictions apply. Which makes chkbss checks for
      uncompressed kernel objects obsolete and they can be removed.
      
      early_nobss.c is also not needed anymore. Parts of it which are still
      relevant are moved to early.c. Kasan initialization code is now called
      directly from head64 (early.c is instrumented and should not be
      executed before kasan shadow memory is set up).
      Reviewed-by: default avatarPhilipp Rudo <prudo@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      2e83e0eb
    • Vasily Gorbik's avatar
      s390/startup: purge obsolete .gitignore patterns · 19413fe0
      Vasily Gorbik authored
      sizes.h and vmlinux.scr.lds are not generated since commit 369f91c3
      ("s390/decompressor: rework uncompressed image info collection").
      
      vmlinux.bin.full is not generated since commit 183ab05f ("s390: get
      rid of the first mb of uncompressed image").
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      19413fe0
    • Vasily Gorbik's avatar
      s390/startup: add initial pgm check handler · da9ed30d
      Vasily Gorbik authored
      The startup code is getting more complicated with features like kaslr and
      secure boot in place. In a potential unexpected startup code crash case
      the system would end up in a pgm check loop at address 0, overwriting
      pgm check old psw value and just making debugging more complicated. To
      avoid that introduce startup program check handler which is active
      immediately after kernel start and until early_pgm_check_handler is set
      in kernel/early.c. So it covers kernel relocation phase and transition
      to it. This pgm check handler simply saves general/control registers and
      psw in the save area which should guarantee that we still have something
      to look at when standalone dumper is called without saving registers. And
      it does disabled wait with a faulty address in the end.
      Acked-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      da9ed30d
    • Chuhong Yuan's avatar
      s390/mm: use refcount_t for refcount · 40e90656
      Chuhong Yuan authored
      Reference counters are preferred to use refcount_t instead of
      atomic_t.
      This is because the implementation of refcount_t can prevent
      overflows and detect possible use-after-free.
      So convert atomic_t ref counters to refcount_t.
      
      Link: http://lkml.kernel.org/r/20190808071826.6649-1-hslester96@gmail.comSigned-off-by: default avatarChuhong Yuan <hslester96@gmail.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      40e90656
    • Chuhong Yuan's avatar
      s390/extmem: use refcount_t for refcount · 3434caec
      Chuhong Yuan authored
      Reference counters are preferred to use refcount_t instead of
      atomic_t.
      This is because the implementation of refcount_t can prevent
      overflows and detect possible use-after-free.
      So convert atomic_t ref counters to refcount_t.
      
      Link: http://lkml.kernel.org/r/20190808071817.6595-1-hslester96@gmail.comSigned-off-by: default avatarChuhong Yuan <hslester96@gmail.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      3434caec
    • Denis Efremov's avatar
      s390/pci: PCI_IOV_RESOURCES loop refactoring in zpci_map_resources · c4c37723
      Denis Efremov authored
      This patch alters the for loop iteration scheme in zpci_map_resources
      to make it more usual. Thus, the patch generalizes the style for
      PCI_IOV_RESOURCES iteration and improves readability.
      
      Link: http://lkml.kernel.org/r/20190806160137.29275-1-efremov@linux.comSigned-off-by: default avatarDenis Efremov <efremov@linux.com>
      Signed-off-by: default avatarSebastian Ott <sebott@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      c4c37723
    • Vasily Gorbik's avatar
      s390: move vmalloc option parsing to startup code · 59793c5a
      Vasily Gorbik authored
      Few other crucial memory setup options are already handled in
      the startup code. Those values are needed by kaslr and kasan
      implementations. "vmalloc" is the last piece required for future
      improvements such as early decision on kernel page levels depth required
      for actual memory setup, as well as vmalloc memory area access monitoring
      in kasan.
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      59793c5a
    • Heiko Carstens's avatar
      Documentation/s390: remove outdated debugging390 documentation · f62f7dcb
      Heiko Carstens authored
      This file would need a lot of work to make sense again. Thomas Huth
      started working on that four years ago, but that wasn't finished.
      Therefore remove this.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      f62f7dcb
    • Heiko Carstens's avatar
      Documentation/s390: remove outdated dasd documentation · 8c72e0c8
      Heiko Carstens authored
      The contents of the file is completely outdated - just remove it.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      8c72e0c8
  7. 29 Jul, 2019 1 commit
    • Harald Freudenberger's avatar
      s390/zcrypt: new sysfs attributes serialnr and mkvps · 7c4e91c0
      Harald Freudenberger authored
      This patch extends the sysfs interface with two new attributes for the
      CEX4, CEX5 and CEX6 crypto cards/queues in coprocessor ('CCA') mode:
        /sys/devices/ap/cardxx/serialnr
        /sys/devices/ap/cardxx/xx.yyyy/mkvps
      
      The serialnr attribute is card based and shows the 8 character ASCII
      serial number string which should unique identify the card.
      
      The mkvps is queue based and displays 3 lines of information about the
      new, current and old master key register:
        AES NEW: <new_aes_mk_state> <new_aes_mk_mkvp>
        AES CUR: <cur_aes_mk_state> <cur_aes_mk_mkvp>
        AES OLD: <old_aes_mk_state> <old_aes_mk_mkvp>
      with
        <new_aes_mk_state>: 'empty' or 'partial' or 'full'
        <cur_aes_mk_state>: 'valid' or 'invalid'
        <old_aes_mk_state>: 'valid' or 'invalid'
        <new_aes_mk_mkvp>, <cur_aes_mk_mkvp>, <old_aes_mk_mkvp>
          8 byte hex string with leading 0x
      MKVP means Master Key Verification Pattern and is a folded hash over
      the key value. Only the states 'full' and 'valid' result in displaying
      a useful mkvp, otherwise a mkvp of all bytes zero is shown. If for any
      reason the FQ fails and the (cached) information is not available, the
      state '-' will be shown with the mkvp value also '-'. The values shown
      here are the very same as the cca panel tools displays. As of now only
      the AES master keys states and verification patterns are shown. A CCA
      APQN also has similar master key registers for DES, RSA and ECC. So
      the content of this attribute may get extended.
      
      Reading the sysfs attribute automatically triggers an FQ CPRB to be
      sent to the queue as long as the queue is (soft-) online. For the
      serialnr attribute the queue with the default domain id is addressed
      (if available and valid). This is reasonable as it is assumed that
      this sysfs interface is not performance critical and on the other side
      a master key change should be visiable as soon as possible. When a
      queue is (soft-) offline however, the cached values are displayed. If
      no cached values are available, the serial number string will be empty
      and the mkvp lines will show state '-' and mkvp value '-'.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarIngo Franzki <ifranzki@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      7c4e91c0