01 Nov, 2011

1 commit


27 Jul, 2011

1 commit

  • This allows us to move duplicated code in
    (atomic_inc_not_zero() for now) to

    Signed-off-by: Arun Sharma
    Reviewed-by: Eric Dumazet
    Cc: Ingo Molnar
    Cc: David Miller
    Cc: Eric Dumazet
    Acked-by: Mike Frysinger
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arun Sharma
     

09 Dec, 2009

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
    hwrng: core - Prevent too-small buffer sizes
    hwrng: virtio-rng - Convert to new API
    hwrng: core - Replace u32 in driver API with byte array
    crypto: ansi_cprng - Move FIPS functions under CONFIG_CRYPTO_FIPS
    crypto: testmgr - Add ghash algorithm test before provide to users
    crypto: ghash-clmulni-intel - Put proper .data section in place
    crypto: ghash-clmulni-intel - Use gas macro for PCLMULQDQ-NI and PSHUFB
    crypto: aesni-intel - Use gas macro for AES-NI instructions
    x86: Generate .byte code for some new instructions via gas macro
    crypto: ghash-intel - Fix irq_fpu_usable usage
    crypto: ghash-intel - Add PSHUFB macros
    crypto: ghash-intel - Hard-code pshufb
    crypto: ghash-intel - Fix building failure on x86_32
    crypto: testmgr - Fix warning
    crypto: ansi_cprng - Fix test in get_prng_bytes
    crypto: hash - Remove cra_u.{digest,hash}
    crypto: api - Remove digest case from procfs show handler
    crypto: hash - Remove legacy hash/digest code
    crypto: ansi_cprng - Add FIPS wrapper
    crypto: ghash - Add PCLMULQDQ accelerated implementation

    Linus Torvalds
     

19 Nov, 2009

1 commit


12 Nov, 2009

1 commit


19 Oct, 2009

1 commit


25 Dec, 2008

1 commit

  • This patch makes /proc/crypto call the type-specific show function
    if one is present before calling the legacy show functions for
    cipher/digest/compress. This allows us to reuse the type values
    for those legacy types. In particular, hash and digest will share
    one type value while shash is phased in as the default hash type.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

29 Aug, 2008

3 commits

  • Add the ability to turn FIPS-compliant mode on or off at boot

    In order to be FIPS compliant, several check may need to be preformed that may
    be construed as unusefull in a non-compliant mode. This patch allows us to set
    a kernel flag incating that we are running in a fips-compliant mode from boot
    up. It also exports that mode information to user space via a sysctl
    (/proc/sys/crypto/fips_enabled).

    Tested successfully by me.

    Signed-off-by: Neil Horman
    Signed-off-by: Herbert Xu

    Neil Horman
     
  • This patch makes use of the new testing infrastructure by requiring
    algorithms to pass a run-time test before they're made available to
    users.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • Rather than displaying larval objects as real objects, this patch
    makes them show up under /proc/crypto as of type larval.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

21 Apr, 2008

2 commits


17 Jul, 2007

1 commit


13 Feb, 2007

1 commit

  • Many struct file_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

21 Sep, 2006

3 commits

  • This patch adds the crypto_type structure which will be used for all new
    crypto algorithm types, beginning with block ciphers.

    The primary purpose of this abstraction is to allow different crypto_type
    objects for crypto algorithms of the same type, in particular, there will
    be a different crypto_type objects for asynchronous algorithms.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • The crypto API is made up of the part facing users such as IPsec and the
    low-level part which is used by cryptographic entities such as algorithms.
    This patch splits out the latter so that the two APIs are more clearly
    delineated. As a bonus the low-level API can now be modularised if all
    algorithms are built as modules.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • Up until now we've relied on module reference counting to ensure that the
    crypto_alg structures don't disappear from under us. This was good enough
    as long as each crypto_alg came from exactly one module.

    However, with parameterised crypto algorithms a crypto_alg object may need
    two or more modules to operate. This means that we need to count the
    references to the crypto_alg object directly.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

10 Jan, 2006

1 commit

  • This is the first step on the road towards asynchronous support in
    the Crypto API. It adds support for having multiple crypto_alg objects
    for the same algorithm registered in the system.

    For example, each device driver would register a crypto_alg object
    for each algorithm that it supports. While at the same time the
    user may load software implementations of those same algorithms.

    Users of the Crypto API may then select a specific implementation
    by name, or choose any implementation for a given algorithm with
    the highest priority.

    The priority field is a 32-bit signed integer. In future it will be
    possible to modify it from user-space.

    This also provides a solution to the problem of selecting amongst
    various AES implementations, that is, aes vs. aes-i586 vs. aes-padlock.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds