11 Jul, 2007

1 commit


19 May, 2007

1 commit

  • The function crypto_mod_put first frees the algorithm and then drops
    the reference to its module. Unfortunately we read the module pointer
    which after freeing the algorithm and that pointer sits inside the
    object that we just freed.

    So this patch reads the module pointer out before we free the object.

    Thanks to Luca Tettamanti for reporting this.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

07 Feb, 2007

2 commits


07 Dec, 2006

1 commit

  • This patch removes the following no longer used functions:
    - api.c: crypto_alg_available()
    - digest.c: crypto_digest_init()
    - digest.c: crypto_digest_update()
    - digest.c: crypto_digest_final()
    - digest.c: crypto_digest_digest()

    Signed-off-by: Adrian Bunk
    Signed-off-by: Herbert Xu

    Adrian Bunk
     

11 Oct, 2006

1 commit

  • This patch makes crypto_alloc_base() return proper return value.

    - If kzalloc() failure happens within __crypto_alloc_tfm(),
    crypto_alloc_base() returns NULL. But crypto_alloc_base()
    is supposed to return error code as pointer. So this patch
    makes it return -ENOMEM in that case.

    - crypto_alloc_base() is suppose to return -EINTR, if it is
    interrupted by signal. But it may not return -EINTR.

    Signed-off-by: Akinobu Mita
    Signed-off-by: Herbert Xu

    Akinobu Mita
     

21 Sep, 2006

11 commits

  • This patch adds the crypto_comp type to complete the compile-time checking
    conversion. The functions crypto_has_alg and crypto_has_cipher, etc. are
    also added to replace crypto_alg_available.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • 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
     
  • Up until now all crypto transforms have been of the same type, struct
    crypto_tfm, regardless of whether they are ciphers, digests, or other
    types. As a result of that, we check the types at run-time before
    each crypto operation.

    This is rather cumbersome. We could instead use different C types for
    each crypto type to ensure that the correct types are used at compile
    time. That is, we would have crypto_cipher/crypto_digest instead of
    just crypto_tfm. The appropriate type would then be required for the
    actual operations such as crypto_digest_digest.

    Now that we have the type/mask fields when looking up algorithms, it
    is easy to request for an algorithm of the precise type that the user
    wants. However, crypto_alloc_tfm currently does not expose these new
    attributes.

    This patch introduces the function crypto_alloc_base which will carry
    these new parameters. It will be renamed to crypto_alloc_tfm once
    all existing users have been converted.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • This patch adds the asynchronous flag and changes all existing users to
    only look up algorithms that are synchronous.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • Spawns lock a specific crypto algorithm in place. They can then be used
    with crypto_spawn_tfm to allocate a tfm for that algorithm. When the base
    algorithm of a spawn is deregistered, all its spawns will be automatically
    removed.

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

    Herbert Xu
     
  • This patch also adds the infrastructure to pick an algorithm based on
    their type. For example, this allows you to select the encryption
    algorithm "aes", instead of any algorithm registered under the name
    "aes". For now this is only accessible internally. Eventually it
    will be made available through crypto_alloc_tfm.

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

    Herbert Xu
     
  • The cryptomgr module is a simple manager of crypto algorithm instances.
    It ensures that parameterised algorithms of the type tmpl(alg) (e.g.,
    cbc(aes)) are always created.

    This is meant to satisfy the needs for most users. For more complex
    cases such as deeper combinations or multiple parameters, a netlink
    module will be created which allows arbitrary expressions to be parsed
    in user-space.

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

    Herbert Xu
     
  • This patch adds a notifier chain for algorithm/template registration events.
    This will be used to register compound algorithms such as cbc(aes). In
    future this will also be passed onto user-space through netlink.

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

    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
     
  • The functions crypto_alg_get and crypto_alg_put operates on the crypto
    modules rather than the algorithms. Therefore it makes sense to call
    them crypto_mod_get and crypto_alg_put respectively.

    This is needed because we need to have real algorithm reference counters
    for parameterised algorithms as they can be unregistered from below by
    when their parameter algorithms are themselves unregistered.

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

    Herbert Xu
     

26 Jun, 2006

3 commits

  • We already allow asynchronous removal of existing algorithm modules. By
    allowing the replacement of existing algorithms, we can replace algorithms
    without having to wait for for all existing users to complete.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • We do need to change these names now and even more so in future with
    instantiated algorithms. So let's stop lying to the compiler and get
    rid of the const modifiers.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • This patch adds the hooks cra_init/cra_exit which are called during a tfm's
    construction and destruction respectively. This will be used by the instances
    to allocate child tfm's.

    For now this lets us get rid of the coa_init/coa_exit functions which are
    used for exactly that purpose (unlike the dia_init function which is called
    for each transaction).

    In fact the coa_exit path is currently buggy as it may get called twice
    when an error is encountered during initialisation.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

21 Mar, 2006

2 commits

  • this patch converts crypto/ to kzalloc usage.
    Compile tested with allyesconfig.

    Signed-off-by: Eric Sesterhenn
    Signed-off-by: Herbert Xu

    Eric Sesterhenn
     
  • Since tfm contexts can contain arbitrary types we should provide at least
    natural alignment (__attribute__ ((__aligned__))) for them. In particular,
    this is needed on the Xscale which is a 32-bit architecture with a u64 type
    that requires 64-bit alignment. This problem was reported by Ronen Shitrit.

    The crypto_tfm structure's size was 44 bytes on 32-bit architectures and
    80 bytes on 64-bit architectures. So adding this requirement only means
    that we have to add an extra 4 bytes on 32-bit architectures.

    On i386 the natural alignment is 16 bytes which also benefits the VIA
    Padlock as it no longer has to manually align its context structure to
    128 bits.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

10 Jan, 2006

2 commits

  • The cipher code path may allocate up to two blocks of data on the stack.
    Therefore we need to place limits on the maximum block size.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • 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
     

30 Oct, 2005

1 commit


02 Sep, 2005

1 commit

  • The crypto layer currently uses in_atomic() to determine whether it is
    allowed to sleep. This is incorrect since spin locks don't always cause
    in_atomic() to return true.

    Instead of that, this patch returns to an earlier idea of a per-tfm flag
    which determines whether sleeping is allowed. Unlike the earlier version,
    the default is to not allow sleeping. This ensures that no existing code
    can break.

    As usual, this flag may either be set through crypto_alloc_tfm(), or
    just before a specific crypto operation.

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

    Herbert Xu
     

07 Jul, 2005

4 commits

  • As far as I'm aware there's a general concensus that functions that are
    responsible for freeing resources should be able to cope with being passed
    a NULL pointer. This makes sense as it removes the need for all callers to
    check for NULL, thus elliminating the bugs that happen when some forget
    (safer to just check centrally in the freeing function) and it also makes
    for smaller code all over due to the lack of all those NULL checks.
    This patch makes it safe to pass the crypto_free_tfm() function a NULL
    pointer. Once this patch is applied we can start removing the NULL checks
    from the callers.

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

    Jesper Juhl
     
  • This patch ensures that cit_iv is aligned according to cra_alignmask
    by allocating it as part of the tfm structure. As a side effect the
    crypto layer will also guarantee that the tfm ctx area has enough space
    to be aligned by cra_alignmask. This allows us to remove the extra
    space reservation from the Padlock driver.

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

    Herbert Xu
     
  • This patch makes a needlessly global function static.

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

    Adrian Bunk
     
  • The VIA Padlock device requires the input and output buffers to
    be aligned on 16-byte boundaries. This patch adds the alignmask
    attribute for low-level cipher implementations to indicate their
    alignment requirements.

    The mid-level crypt() function will copy the input/output buffers
    if they are not aligned correctly before they are passed to the
    low-level implementation.

    Strictly speaking, some of the software implementations require
    the buffers to be aligned on 4-byte boundaries as they do 32-bit
    loads. However, it is not clear whether it is better to copy
    the buffers or pay the penalty for unaligned loads/stores.

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

    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