1. 07 2月, 2007 1 次提交
  2. 07 12月, 2006 3 次提交
  3. 16 10月, 2006 1 次提交
  4. 21 9月, 2006 11 次提交
  5. 26 6月, 2006 1 次提交
  6. 10 1月, 2006 1 次提交
  7. 07 1月, 2006 4 次提交
  8. 02 9月, 2005 1 次提交
  9. 07 7月, 2005 1 次提交
    • A
      [CRYPTO] Add x86_64 asm AES · a2a892a2
      Andreas Steinmetz 提交于
      Implementation:
      ===============
      The encrypt/decrypt code is based on an x86 implementation I did a while
      ago which I never published. This unpublished implementation does
      include an assembler based key schedule and precomputed tables. For
      simplicity and best acceptance, however, I took Gladman's in-kernel code
      for table generation and key schedule for the kernel port of my
      assembler code and modified this code to produce the key schedule as
      required by my assembler implementation. File locations and Kconfig are
      kept similar to the i586 AES assembler implementation.
      It may seem a little bit strange to use 32 bit I/O and registers in the
      assembler implementation but this gives the best code size. My
      implementation takes one instruction more per round compared to
      Gladman's x86 assembler but it doesn't require any stack for local
      variables or saved registers and it is less serialized than Gladman's
      code.
      Note that all comparisons to Gladman's code were done after my code was
      implemented. I did only use FIPS PUB 197 for the implementation so my
      implementation is independent work.
      If anybody has a better assembler solution for x86_64 I'll be pleased to
      have my code replaced with the better solution.
      
      Testing:
      ========
      The implementation passes the in-kernel crypto testing module and I'm
      running it without any problems on my laptop where it is mainly used for
      dm-crypt.
      
      Microbenchmark:
      ===============
      The microbenchmark was done in userspace with similar compile flags as
      used during kernel compile.
      Encrypt/decrypt is about 35% faster than the generic C implementation.
      As the generic C as well as my assembler implementation are both table
      I don't really expect that there is much room for further
      improvements though I'll be glad to be corrected here.
      The key schedule is about 5% slower than the generic C implementation.
      This is due to the fact that some more work has to be done in the key
      schedule routine to fit the schedule to the assembler implementation.
      
      Code Size:
      ==========
      Encrypt and decrypt are together about 2.1 Kbytes smaller than the
      generic C implementation which is important with regard to L1 cache
      usage. The key schedule routine is about 100 bytes larger than the
      generic C implementation.
      
      Data Size:
      ==========
      There's no difference in data size requirements between the assembler
      implementation and the generic C implementation.
      
      License:
      ========
      Gladmans's code is dual BSD/GPL whereas my assembler code is GPLv2 only
      (I'm  not going to change the license for my code). So I had to change
      the module license for the x86_64 aes module from 'Dual BSD/GPL' to
      'GPL' to reflect the most restrictive license within the module.
      Signed-off-by: NAndreas Steinmetz <ast@domdv.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2a892a2
  10. 01 5月, 2005 1 次提交
  11. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4