1. 07 3月, 2019 2 次提交
  2. 05 3月, 2019 1 次提交
  3. 28 2月, 2019 12 次提交
  4. 22 2月, 2019 9 次提交
  5. 15 2月, 2019 4 次提交
  6. 08 2月, 2019 4 次提交
  7. 01 2月, 2019 8 次提交
    • H
      crypto: caam - fix DMA mapping of stack memory · c19650d6
      Horia Geantă 提交于
      Roland reports the following issue and provides a root cause analysis:
      
      "On a v4.19 i.MX6 system with IMA and CONFIG_DMA_API_DEBUG enabled, a
      warning is generated when accessing files on a filesystem for which IMA
      measurement is enabled:
      
          ------------[ cut here ]------------
          WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:1181 check_for_stack.part.9+0xd0/0x120
          caam_jr 2101000.jr0: DMA-API: device driver maps memory from stack [addr=b668049e]
          Modules linked in:
          CPU: 0 PID: 1 Comm: switch_root Not tainted 4.19.0-20181214-1 #2
          Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
          Backtrace:
          [<c010efb8>] (dump_backtrace) from [<c010f2d0>] (show_stack+0x20/0x24)
          [<c010f2b0>] (show_stack) from [<c08b04f4>] (dump_stack+0xa0/0xcc)
          [<c08b0454>] (dump_stack) from [<c012b610>] (__warn+0xf0/0x108)
          [<c012b520>] (__warn) from [<c012b680>] (warn_slowpath_fmt+0x58/0x74)
          [<c012b62c>] (warn_slowpath_fmt) from [<c0199acc>] (check_for_stack.part.9+0xd0/0x120)
          [<c01999fc>] (check_for_stack.part.9) from [<c019a040>] (debug_dma_map_page+0x144/0x174)
          [<c0199efc>] (debug_dma_map_page) from [<c065f7f4>] (ahash_final_ctx+0x5b4/0xcf0)
          [<c065f240>] (ahash_final_ctx) from [<c065b3c4>] (ahash_final+0x1c/0x20)
          [<c065b3a8>] (ahash_final) from [<c03fe278>] (crypto_ahash_op+0x38/0x80)
          [<c03fe240>] (crypto_ahash_op) from [<c03fe2e0>] (crypto_ahash_final+0x20/0x24)
          [<c03fe2c0>] (crypto_ahash_final) from [<c03f19a8>] (ima_calc_file_hash+0x29c/0xa40)
          [<c03f170c>] (ima_calc_file_hash) from [<c03f2b24>] (ima_collect_measurement+0x1dc/0x240)
          [<c03f2948>] (ima_collect_measurement) from [<c03f0a60>] (process_measurement+0x4c4/0x6b8)
          [<c03f059c>] (process_measurement) from [<c03f0cdc>] (ima_file_check+0x88/0xa4)
          [<c03f0c54>] (ima_file_check) from [<c02d8adc>] (path_openat+0x5d8/0x1364)
          [<c02d8504>] (path_openat) from [<c02dad24>] (do_filp_open+0x84/0xf0)
          [<c02daca0>] (do_filp_open) from [<c02cf50c>] (do_open_execat+0x84/0x1b0)
          [<c02cf488>] (do_open_execat) from [<c02d1058>] (__do_execve_file+0x43c/0x890)
          [<c02d0c1c>] (__do_execve_file) from [<c02d1770>] (sys_execve+0x44/0x4c)
          [<c02d172c>] (sys_execve) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
          ---[ end trace 3455789a10e3aefd ]---
      
      The cause is that the struct ahash_request *req is created as a
      stack-local variable up in the stack (presumably somewhere in the IMA
      implementation), then passed down into the CAAM driver, which tries to
      dma_single_map the req->result (indirectly via map_seq_out_ptr_result)
      in order to make that buffer available for the CAAM to store the result
      of the following hash operation.
      
      The calling code doesn't know how req will be used by the CAAM driver,
      and there could be other such occurrences where stack memory is passed
      down to the CAAM driver. Therefore we should rather fix this issue in
      the CAAM driver where the requirements are known."
      
      Fix this problem by:
      -instructing the crypto engine to write the final hash in state->caam_ctx
      -subsequently memcpy-ing the final hash into req->result
      
      Cc: <stable@vger.kernel.org> # v4.19+
      Reported-by: NRoland Hieber <rhi@pengutronix.de>
      Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
      Tested-by: NRoland Hieber <rhi@pengutronix.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c19650d6
    • M
      crypto: bcm - remove -I. header search path and unused macro define · 87fec010
      Masahiro Yamada 提交于
      The header search path -I. in kernel Makefiles is very suspicious;
      it allows the compiler to search for headers in the top of $(srctree),
      where obviously no header file exists.
      
      'git grep BCMDRIVER' has no hit. So, this macro is not referenced.
      
      I was able to build this driver without the extra compiler options.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      87fec010
    • M
      crypto: prefix header search paths with $(srctree)/ · 320ca3e5
      Masahiro Yamada 提交于
      Currently, the Kbuild core manipulates header search paths in a crazy
      way [1].
      
      To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
      the search paths in the srctree. Some Makefiles are already written in
      that way, but not all. The goal of this work is to make the notation
      consistent, and finally get rid of the gross hacks.
      
      Having whitespaces after -I does not matter since commit 48f6e3cf
      ("kbuild: do not drop -I without parameter").
      
      [1]: https://patchwork.kernel.org/patch/9632347/Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      320ca3e5
    • V
      crypto: axis - move request unmap outside of the queue lock · 341a64c7
      Vincent Whitchurch 提交于
      The request unmap and bounce buffer copying is currently unnecessarily
      done while holding the queue spin lock.
      Signed-off-by: NLars Persson <larper@axis.com>
      Signed-off-by: NVincent Whitchurch <rabinv@axis.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      341a64c7
    • L
      crypto: axis - use a constant time tag compare · 5997a245
      Lars Persson 提交于
      Avoid plain memcmp() on the AEAD tag value as this could leak
      information through a timing side channel.
      Signed-off-by: NLars Persson <larper@axis.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5997a245
    • L
      crypto: axis - support variable AEAD tag length · 48ef0908
      Lars Persson 提交于
      The implementation assumed that the client always wants the whole 16
      byte AES-GCM tag. Now we respect the requested authentication tag size
      fetched using crypto_aead_authsize().
      Signed-off-by: NLars Persson <larper@axis.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      48ef0908
    • L
      crypto: axis - give DMA the start of the status buffer · 0d1d4824
      Lars Persson 提交于
      The driver was optimized to only do cache maintenance for the last
      word of the dma descriptor status array. Unfortunately an omission
      also passed the last word as the address of the array start to the DMA
      engine. In most cases this goes unnoticed since the hardware aligns
      the address to a 64 byte boundary.
      Signed-off-by: NLars Persson <larper@axis.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0d1d4824
    • L
      crypto: axis - fix for recursive locking from bottom half · c34a8382
      Lars Persson 提交于
      Clients may submit a new requests from the completion callback
      context. The driver was not prepared to receive a request in this
      state because it already held the request queue lock and a recursive
      lock error is triggered.
      
      Now all completions are queued up until we are ready to drop the queue
      lock and then delivered.
      
      The fault was triggered by TCP over an IPsec connection in the LTP
      test suite:
        LTP: starting tcp4_ipsec02 (tcp_ipsec.sh -p ah -m transport -s "100 1000 65535")
        BUG: spinlock recursion on CPU#1, genload/943
         lock: 0xbf3c3094, .magic: dead4ead, .owner: genload/943, .owner_cpu: 1
        CPU: 1 PID: 943 Comm: genload Tainted: G           O    4.9.62-axis5-devel #6
        Hardware name: Axis ARTPEC-6 Platform
         (unwind_backtrace) from [<8010d134>] (show_stack+0x18/0x1c)
         (show_stack) from [<803a289c>] (dump_stack+0x84/0x98)
         (dump_stack) from [<8016e164>] (do_raw_spin_lock+0x124/0x128)
         (do_raw_spin_lock) from [<804de1a4>] (artpec6_crypto_submit+0x2c/0xa0)
         (artpec6_crypto_submit) from [<804def38>] (artpec6_crypto_prepare_submit_hash+0xd0/0x54c)
         (artpec6_crypto_prepare_submit_hash) from [<7f3165f0>] (ah_output+0x2a4/0x3dc [ah4])
         (ah_output [ah4]) from [<805df9bc>] (xfrm_output_resume+0x178/0x4a4)
         (xfrm_output_resume) from [<805d283c>] (xfrm4_output+0xac/0xbc)
         (xfrm4_output) from [<80587928>] (ip_queue_xmit+0x140/0x3b4)
         (ip_queue_xmit) from [<805a13b4>] (tcp_transmit_skb+0x4c4/0x95c)
         (tcp_transmit_skb) from [<8059f218>] (tcp_rcv_state_process+0xdf4/0xdfc)
         (tcp_rcv_state_process) from [<805a7530>] (tcp_v4_do_rcv+0x64/0x1ac)
         (tcp_v4_do_rcv) from [<805a9724>] (tcp_v4_rcv+0xa34/0xb74)
         (tcp_v4_rcv) from [<80581d34>] (ip_local_deliver_finish+0x78/0x2b0)
         (ip_local_deliver_finish) from [<8058259c>] (ip_local_deliver+0xe4/0x104)
         (ip_local_deliver) from [<805d23ec>] (xfrm4_transport_finish+0xf4/0x144)
         (xfrm4_transport_finish) from [<805df564>] (xfrm_input+0x4f4/0x74c)
         (xfrm_input) from [<804de420>] (artpec6_crypto_task+0x208/0x38c)
         (artpec6_crypto_task) from [<801271b0>] (tasklet_action+0x60/0xec)
         (tasklet_action) from [<801266d4>] (__do_softirq+0xcc/0x3a4)
         (__do_softirq) from [<80126d20>] (irq_exit+0xf4/0x15c)
         (irq_exit) from [<801741e8>] (__handle_domain_irq+0x68/0xbc)
         (__handle_domain_irq) from [<801014f0>] (gic_handle_irq+0x50/0x94)
         (gic_handle_irq) from [<80657370>] (__irq_usr+0x50/0x80)
      Signed-off-by: NLars Persson <larper@axis.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c34a8382