Eric Lee / smarc-fsl-linux-kernel

29 Jul, 2011

1 commit

  • 4203223a1   xfrm: Fix key lengths for rfc3686(ctr(aes)) ... Browse Code »
    1

    Fix the min and max bit lengths for AES-CTR (RFC3686) keys.
    The number of bits in key spec is the key length (128/256)
    plus 32 bits of nonce.

    This change takes care of the "Invalid key length" errors
    reported by setkey when specifying 288 bit keys for aes-ctr.

    Signed-off-by: Tushar Gohad
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Tushar Gohad
     

28 Feb, 2011

1 commit

17 Jan, 2010

1 commit

  • 73c89c15b   crypto: gcm - Add RFC4543 wrapper for GCM ... Browse Code »

    This patch adds the RFC4543 (GMAC) wrapper for GCM similar to the
    existing RFC4106 wrapper. The main differences between GCM and GMAC are
    the contents of the AAD and that the plaintext is empty for the latter.

    Signed-off-by: Tobias Brunner
    Signed-off-by: Herbert Xu

    Tobias Brunner
     

02 Dec, 2009

2 commits

26 Nov, 2009

1 commit

19 Oct, 2009

1 commit

25 Jun, 2009

1 commit

09 Jun, 2009

1 commit

26 Jul, 2008

1 commit

  • 547b792ca   net: convert BUG_TRAP to generic WARN_ON ... Browse Code »

    Removes legacy reinvent-the-wheel type thing. The generic
    machinery integrates much better to automated debugging aids
    such as kerneloops.org (and others), and is unambiguous due to
    better naming. Non-intuively BUG_TRAP() is actually equal to
    WARN_ON() rather than BUG_ON() though some might actually be
    promoted to BUG_ON() but I left that to future.

    I could make at least one BUILD_BUG_ON conversion.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     

05 Jun, 2008

1 commit

28 Apr, 2008

1 commit

  • 01a2202c9   [IPSEC]: Use digest_null directly for auth ... Browse Code »

    Previously digest_null had no setkey function which meant that
    we used hmac(digest_null) for IPsec since IPsec always calls
    setkey. Now that digest_null has a setkey we no longer need to
    do that.

    In fact when only confidentiality is specified for ESP we already
    use digest_null directly. However, when the null algorithm is
    explicitly specified by the user we still opt for hmac(digest_null).

    This patch removes this discrepancy. I have not added a new compat
    name for it because by chance it wasn't actualy possible for the user
    to specify the name hmac(digest_null) due to a key length check in
    xfrm_user (which I found out when testing that compat name :)

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

    Herbert Xu
     

08 Feb, 2008

1 commit

01 Feb, 2008

2 commits

  • 1a6509d99   [IPSEC]: Add support for combined mode algorithms ... Browse Code »

    This patch adds support for combined mode algorithms with GCM being
    the first algorithm supported.

    Combined mode algorithms can be added through the xfrm_user interface
    using the new algorithm payload type XFRMA_ALG_AEAD. Each algorithms
    is identified by its name and the ICV length.

    For the purposes of matching algorithms in xfrm_tmpl structures,
    combined mode algorithms occupy the same name space as encryption
    algorithms. This is in line with how they are negotiated using IKE.

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

    Herbert Xu
     
  • 6fbf2cb77   [IPSEC]: Allow async algorithms ... Browse Code »

    Now that ESP uses authenc we can turn on the support for async
    algorithms in IPsec.

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

    Herbert Xu
     

29 Jan, 2008

1 commit

02 Nov, 2007

1 commit

26 Oct, 2007

1 commit

24 Oct, 2007

1 commit

23 Oct, 2007

2 commits

23 May, 2007

1 commit

20 May, 2007

1 commit

  • c92b3a2f1   [IPSEC] pfkey: Load specific algorithm in pfkey_add rather than all ... Browse Code »

    This is a natural extension of the changeset

    [XFRM]: Probe selected algorithm only.

    which only removed the probe call for xfrm_user. This patch does exactly
    the same thing for af_key. In other words, we load the algorithm requested
    by the user rather than everything when adding xfrm states in af_key.

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

    Herbert Xu
     

28 Apr, 2007

1 commit

  • 1a028e507   [NET]: Revert sk_buff walker cleanups. ... Browse Code »

    This reverts eefa3906283a2b60a6d02a2cda593a7d7d7946c5

    The simplification made in that change works with the assumption that
    the 'offset' parameter to these functions is always positive or zero,
    which is not true. It can be and often is negative in order to access
    SKB header values in front of skb->data.

    Signed-off-by: David S. Miller

    David S. Miller
     

26 Apr, 2007

2 commits

  • eefa39062   [NET]: Clean up sk_buff walkers. ... Browse Code »

    I noticed recently that, in skb_checksum(), "offset" and "start" are
    essentially the same thing and have the same value throughout the
    function, despite being computed differently. Using a single variable
    allows some cleanups and makes the skb_checksum() function smaller,
    more readable, and presumably marginally faster.

    We appear to have many other "sk_buff walker" functions built on the
    exact same model, so the cleanup applies to them, too. Here is a list
    of the functions I found to be affected:

    net/appletalk/ddp.c:atalk_sum_skb()
    net/core/datagram.c:skb_copy_datagram_iovec()
    net/core/datagram.c:skb_copy_and_csum_datagram()
    net/core/skbuff.c:skb_copy_bits()
    net/core/skbuff.c:skb_store_bits()
    net/core/skbuff.c:skb_checksum()
    net/core/skbuff.c:skb_copy_and_csum_bit()
    net/core/user_dma.c:dma_skb_copy_datagram_iovec()
    net/xfrm/xfrm_algo.c:skb_icv_walk()
    net/xfrm/xfrm_algo.c:skb_to_sgvec()

    OTOH, I admit I'm a bit surprised, the cleanup is rather obvious so I'm
    really wondering if I am missing something. Can anyone please comment
    on this?

    Signed-off-by: Jean Delvare
    Signed-off-by: David S. Miller

    Jean Delvare
     
  • 716ea3a7a   [NET]: Move generic skbuff stuff from XFRM code to generic code ... Browse Code »

    Move generic skbuff stuff from XFRM code to generic code so that
    AF_RXRPC can use it too.

    The kdoc comments I've attached to the functions needs to be checked
    by whoever wrote them as I had to make some guesses about the workings
    of these functions.

    Signed-off-By: David Howells
    Signed-off-by: David S. Miller

    David Howells
     

11 Feb, 2007

1 commit

07 Feb, 2007

1 commit

01 Jan, 2007

1 commit

  • b836267aa   [XFRM]: Algorithm lookup using .compat name ... Browse Code »

    Installing an IPsec SA using old algorithm names (.compat) does not work
    if the algorithm is not already loaded. When not using the PF_KEY
    interface, algorithms are not preloaded in xfrm_probe_algs() and
    installing a IPsec SA fails.

    Signed-off-by: Martin Willi
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Martin Willi
     

07 Dec, 2006

1 commit

21 Sep, 2006

4 commits

01 Jul, 2006

1 commit

10 Jan, 2006

1 commit

19 May, 2005

1 commit

  • d48102007   [XFRM]: skb_cow_data() does not set proper owner for new skbs. ... Browse Code »

    It looks like skb_cow_data() does not set
    proper owner for newly created skb.

    If we have several fragments for skb and some of them
    are shared(?) or cloned (like in async IPsec) there
    might be a situation when we require recreating skb and
    thus using skb_copy() for it.
    Newly created skb has neither a destructor nor a socket
    assotiated with it, which must be copied from the old skb.
    As far as I can see, current code sets destructor and socket
    for the first one skb only and uses truesize of the first skb
    only to increment sk_wmem_alloc value.

    If above "analysis" is correct then attached patch fixes that.

    Signed-off-by: Evgeniy Polyakov
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Evgeniy Polyakov
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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