1. 23 1月, 2017 2 次提交
    • D
      crypto: x86 - make constants readonly, allow linker to merge them · e183914a
      Denys Vlasenko 提交于
      A lot of asm-optimized routines in arch/x86/crypto/ keep its
      constants in .data. This is wrong, they should be on .rodata.
      
      Mnay of these constants are the same in different modules.
      For example, 128-bit shuffle mask 0x000102030405060708090A0B0C0D0E0F
      exists in at least half a dozen places.
      
      There is a way to let linker merge them and use just one copy.
      The rules are as follows: mergeable objects of different sizes
      should not share sections. You can't put them all in one .rodata
      section, they will lose "mergeability".
      
      GCC puts its mergeable constants in ".rodata.cstSIZE" sections,
      or ".rodata.cstSIZE.<object_name>" if -fdata-sections is used.
      This patch does the same:
      
      	.section .rodata.cst16.SHUF_MASK, "aM", @progbits, 16
      
      It is important that all data in such section consists of
      16-byte elements, not larger ones, and there are no implicit
      use of one element from another.
      
      When this is not the case, use non-mergeable section:
      
      	.section .rodata[.VAR_NAME], "a", @progbits
      
      This reduces .data by ~15 kbytes:
      
          text    data     bss     dec      hex filename
      11097415 2705840 2630712 16433967  fac32f vmlinux-prev.o
      11112095 2690672 2630712 16433479  fac147 vmlinux.o
      
      Merged objects are visible in System.map:
      
      ffffffff81a28810 r POLY
      ffffffff81a28810 r POLY
      ffffffff81a28820 r TWOONE
      ffffffff81a28820 r TWOONE
      ffffffff81a28830 r PSHUFFLE_BYTE_FLIP_MASK <- merged regardless of
      ffffffff81a28830 r SHUF_MASK   <------------- the name difference
      ffffffff81a28830 r SHUF_MASK
      ffffffff81a28830 r SHUF_MASK
      ..
      ffffffff81a28d00 r K512 <- merged three identical 640-byte tables
      ffffffff81a28d00 r K512
      ffffffff81a28d00 r K512
      
      Use of object names in section name suffixes is not strictly necessary,
      but might help if someday link stage will use garbage collection
      to eliminate unused sections (ld --gc-sections).
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      CC: Herbert Xu <herbert@gondor.apana.org.au>
      CC: Josh Poimboeuf <jpoimboe@redhat.com>
      CC: Xiaodong Liu <xiaodong.liu@intel.com>
      CC: Megha Dey <megha.dey@intel.com>
      CC: linux-crypto@vger.kernel.org
      CC: x86@kernel.org
      CC: linux-kernel@vger.kernel.org
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      e183914a
    • D
      crypto: x86/crc32c - fix %progbits -> @progbits · 587d531b
      Denys Vlasenko 提交于
      %progbits form is used on ARM (where @ is a comment char).
      
      x86 consistently uses @progbits everywhere else.
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      CC: Herbert Xu <herbert@gondor.apana.org.au>
      CC: Josh Poimboeuf <jpoimboe@redhat.com>
      CC: Xiaodong Liu <xiaodong.liu@intel.com>
      CC: Megha Dey <megha.dey@intel.com>
      CC: George Spelvin <linux@horizon.com>
      CC: linux-crypto@vger.kernel.org
      CC: x86@kernel.org
      CC: linux-kernel@vger.kernel.org
      Reviewed-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      587d531b
  2. 13 1月, 2017 1 次提交
  3. 27 12月, 2016 2 次提交
  4. 28 11月, 2016 2 次提交
  5. 17 11月, 2016 1 次提交
  6. 12 11月, 2016 1 次提交
    • A
      crypto: aesni: shut up -Wmaybe-uninitialized warning · beae2c9e
      Arnd Bergmann 提交于
      The rfc4106 encrypy/decrypt helper functions cause an annoying
      false-positive warning in allmodconfig if we turn on
      -Wmaybe-uninitialized warnings again:
      
        arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’:
        include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      The problem seems to be that the compiler doesn't track the state of the
      'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end
      section.
      
      This takes the easy way out by adding a bogus initialization, which
      should be harmless enough to get the patch into v4.9 so we can turn on
      this warning again by default without producing useless output.  A
      follow-up patch for v4.10 rearranges the code to make the warning go
      away.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      beae2c9e
  7. 07 10月, 2016 2 次提交
  8. 16 8月, 2016 2 次提交
  9. 20 7月, 2016 1 次提交
    • P
      x86, crypto: Restore MODULE_LICENSE() to glue_helper.c so it loads · a47177d3
      Paul Gortmaker 提交于
      In commit:
      
        eb008eb6 ("x86: Audit and remove any remaining unnecessary uses of module.h")
      
      ... we looked for instances of module.h that were not supporting anything
      more than exported symbols.
      
      To facilitate the exchange of module.h to the much smaller export.h
      we occasionally remove tags like MODULE_AUTHOR() etc. which in the case
      of built in files, are no-ops and hence that is fine, assuming the
      info is already in the comments at the top of the file..
      
      However the error here is that I overlooked that this file was used
      not as a driver, but as a library of functions, and hence has no
      explicit modular linkage functions or similar, making it _appear_
      non-modular.  We can see that in retrospect with:
      
        arch/x86/crypto/Makefile:obj-$(CONFIG_CRYPTO_GLUE_HELPER_X86) += glue_helper.o
      
        crypto/Kconfig:config CRYPTO_GLUE_HELPER_X86
        crypto/Kconfig: tristate
      
      Since we removed what was an active MODULE_LICENSE(), the module failed
      to load and then automated testing showed the missing glue helpers as:
      
        glue_helper: Unknown symbol blkcipher_walk_done (err 0)
        glue_helper: Unknown symbol blkcipher_walk_virt (err 0)
        glue_helper: Unknown symbol kernel_fpu_end (err 0)
        glue_helper: Unknown symbol kernel_fpu_begin (err 0)
        glue_helper: Unknown symbol blkcipher_walk_virt_block (err 0)
      
      So we do a partial revert of that change to just this one file, and
      watch for similar MODULE_LICENSE() only cases in future audits.
      Reported-by: Nkernel test robot <xiaolong.ye@intel.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-crypto@vger.kernel.org
      Cc: lkp@01.org
      Fixes: eb008eb6 ("x86: Audit and remove any remaining unnecessary uses of module.h")
      Link: http://lkml.kernel.org/r/20160719144243.GK21225@windriver.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a47177d3
  10. 14 7月, 2016 1 次提交
    • P
      x86: Audit and remove any remaining unnecessary uses of module.h · eb008eb6
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  In the case of
      some of these which are modular, we can extend that to also include
      files that are building basic support functionality but not related
      to loading or registering the final module; such files also have
      no need whatsoever for module.h
      
      The advantage in removing such instances is that module.h itself
      sources about 15 other headers; adding significantly to what we feed
      cpp, and it can obscure what headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each instance for the
      presence of either and replace as needed.
      
      In the case of crypto/glue_helper.c we delete a redundant instance
      of MODULE_LICENSE in order to delete module.h -- the license info
      is already present at the top of the file.
      
      The uncore change warrants a mention too; it is uncore.c that uses
      module.h and not uncore.h; hence the relocation done there.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160714001901.31603-9-paul.gortmaker@windriver.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      eb008eb6
  11. 12 7月, 2016 1 次提交
  12. 01 7月, 2016 1 次提交
    • H
      crypto: aesni - Use crypto_cipher to derive rfc4106 subkey · 02fa472a
      Herbert Xu 提交于
      Currently aesni uses an async ctr(aes) to derive the rfc4106
      subkey, which was presumably copied over from the generic rfc4106
      code.  Over there it's done that way because we already have a
      ctr(aes) spawn.  But it is simply overkill for aesni since we
      have to go get a ctr(aes) from scratch anyway.
      
      This patch simplifies the subkey derivation by using a straight
      aes cipher instead.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      02fa472a
  13. 28 6月, 2016 4 次提交
  14. 27 6月, 2016 5 次提交
  15. 23 6月, 2016 4 次提交
  16. 02 6月, 2016 1 次提交
  17. 31 5月, 2016 1 次提交
  18. 17 5月, 2016 1 次提交
    • J
      crypto: sha1-mb - make sha1_x8_avx2() conform to C function ABI · 4a6b27b7
      Josh Poimboeuf 提交于
      Megha Dey reported a kernel panic in crypto code.  The problem is that
      sha1_x8_avx2() clobbers registers r12-r15 without saving and restoring
      them.
      
      Before commit aec4d0e3 ("x86/asm/crypto: Simplify stack usage in
      sha-mb functions"), those registers were saved and restored by the
      callers of the function.  I removed them with that commit because I
      didn't realize sha1_x8_avx2() clobbered them.
      
      Fix the potential undefined behavior associated with clobbering the
      registers and make the behavior less surprising by changing the
      registers to be callee saved/restored to conform with the C function
      call ABI.
      
      Also, rdx (aka RSP_SAVE) doesn't need to be saved: I verified that none
      of the callers rely on it being saved, and it's not a callee-saved
      register in the C ABI.
      
      Fixes: aec4d0e3 ("x86/asm/crypto: Simplify stack usage in sha-mb functions")
      Cc: stable@vger.kernel.org # 4.6
      Reported-by: NMegha Dey <megha.dey@linux.intel.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4a6b27b7
  19. 16 4月, 2016 1 次提交
    • D
      x86: Fix non-static inlines · a3819e3e
      Denys Vlasenko 提交于
      Four instances of incorrect usage of non-static "inline" crept up
      in arch/x86, all trivial; cleaning them up:
      
      EVT_TO_HPET_DEV() - made static, it is only used in kernel/hpet.c
      
      Debug version of check_iommu_entries() is an __init function.
      Non-debug dummy empty version of it is declared "inline" instead -
      which doesn't help to eliminate it (the caller is in a different unit,
      inlining doesn't happen).
      Switch to non-inlined __init function, which does eliminate it
      (by discarding it as part of __init section).
      
      crypto/sha-mb/sha1_mb.c: looks like they just forgot to add "static"
      to their two internal inlines, which emitted two unused functions into
      vmlinux.
      
            text     data      bss       dec     hex filename
        95903394 20860288 35991552 152755234 91adc22 vmlinux_before
        95903266 20860288 35991552 152755106 91adba2 vmlinux
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1460739626-12179-1-git-send-email-dvlasenk@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a3819e3e
  20. 15 4月, 2016 1 次提交
  21. 13 4月, 2016 3 次提交
  22. 31 3月, 2016 2 次提交