1. 16 Sep, 2019 3 commits
  2. 13 Sep, 2019 3 commits
  3. 05 Sep, 2019 3 commits
  4. 03 Sep, 2019 2 commits
  5. 29 Aug, 2019 7 commits
  6. 26 Aug, 2019 7 commits
  7. 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
  8. 21 Aug, 2019 14 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