28 Mar, 2008

1 commit


27 Mar, 2008

1 commit

  • The IPv6 BEET output function is incorrectly including the inner
    header in the payload to be protected. This causes a crash as
    the packet doesn't actually have that many bytes for a second
    header.

    The IPv4 BEET output on the other hand is broken when it comes
    to handling an inner IPv6 header since it always assumes an
    inner IPv4 header.

    This patch fixes both by making sure that neither BEET output
    function touches the inner header at all. All access is now
    done through the protocol-independent cb structure. Two new
    attributes are added to make this work, the IP header length
    and the IPv4 option length. They're filled in by the inner
    mode's output function.

    Thanks to Joakim Koskela for finding this problem.

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

    Herbert Xu
     

25 Mar, 2008

1 commit


29 Jan, 2008

8 commits

  • The xfrm initialization function does not return any error code, so if
    there is an error, the caller can not be advise of that. This patch
    checks the return code of the different called functions in order to
    return a successful or failed initialization.

    Signed-off-by: Daniel Lezcano
    Acked-by: Benjamin Thery
    Signed-off-by: David S. Miller

    Daniel Lezcano
     
  • After changeset:

    [NETFILTER]: Introduce NF_INET_ hook values

    It always evaluates to NF_INET_POST_ROUTING.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • The IPv4 and IPv6 hook values are identical, yet some code tries to figure
    out the "correct" value by looking at the address family. Introduce NF_INET_*
    values for both IPv4 and IPv6. The old values are kept in a #ifndef __KERNEL__
    section for userspace compatibility.

    Signed-off-by: Patrick McHardy
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Patrick McHardy
     
  • The nhoff field isn't actually necessary in xfrm_input. For tunnel
    mode transforms we now throw away the output IP header so it makes no
    sense to fill in the nexthdr field. For transport mode we can now let
    the function transport_finish do the setting and it knows where the
    nexthdr field is.

    The only other thing that needs the nexthdr field to be set is the
    header extraction code. However, we can simply move the protocol
    extraction out of the generic header extraction.

    We want to minimise the amount of info we have to carry around between
    transforms as this simplifies the resumption process for async crypto.

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

    Herbert Xu
     
  • As part of the work on asynchronous cryptographic operations, we need
    to be able to resume from the spot where they occur. As such, it
    helps if we isolate them to one spot.

    This patch moves most of the remaining family-specific processing into
    the common input code.

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

    Herbert Xu
     
  • As part of the work on asynchrnous cryptographic operations, we need
    to be able to resume from the spot where they occur. As such, it
    helps if we isolate them to one spot.

    This patch moves most of the remaining family-specific processing into
    the common output code.

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

    Herbert Xu
     
  • With inter-family transforms the inner mode differs from the outer
    mode. Attempting to handle both sides from the same function means
    that it needs to handle both IPv4 and IPv6 which creates duplication
    and confusion.

    This patch separates the two parts on the input path so that each
    function deals with one family only.

    In particular, the functions xfrm4_extract_inut/xfrm6_extract_inut
    moves the pertinent fields from the IPv4/IPv6 IP headers into a
    neutral format stored in skb->cb. This is then used by the inner mode
    input functions to modify the inner IP header. In this way the input
    function no longer has to know about the outer address family.

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

    Herbert Xu
     
  • With inter-family transforms the inner mode differs from the outer
    mode. Attempting to handle both sides from the same function means
    that it needs to handle both IPv4 and IPv6 which creates duplication
    and confusion.

    This patch separates the two parts on the output path so that each
    function deals with one family only.

    In particular, the functions xfrm4_extract_output/xfrm6_extract_output
    moves the pertinent fields from the IPv4/IPv6 IP headers into a
    neutral format stored in skb->cb. This is then used by the outer mode
    output functions to write the outer IP header. In this way the output
    function no longer has to know about the inner address family.

    Since the extract functions are only called by tunnel modes (the only
    modes that can support inter-family transforms), I've also moved the
    xfrm*_tunnel_check_size calls into them. This allows the correct ICMP
    message to be sent as opposed to now where you might call icmp_send
    with an IPv6 packet and vice versa.

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

    Herbert Xu
     

18 Oct, 2007

2 commits

  • It is convenient to have a pointer from xfrm_state to address-specific
    functions such as the output function for a family. Currently the
    address-specific policy code calls out to the xfrm state code to get
    those pointers when we could get it in an easier way via the state
    itself.

    This patch adds an xfrm_state_afinfo to xfrm_mode (since they're
    address-specific) and changes the policy code to use it. I've also
    added an owner field to do reference counting on the module providing
    the afinfo even though it isn't strictly necessary today since IPv6
    can't be unloaded yet.

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

    Herbert Xu
     
  • Currently BEET mode does not reinject the packet back into the stack
    like tunnel mode does. Since BEET should behave just like tunnel mode
    this is incorrect.

    This patch fixes this by introducing a flags field to xfrm_mode that
    tells the IPsec code whether it should terminate and reinject the packet
    back into the stack.

    It then sets the flag for BEET and tunnel mode.

    I've also added a number of missing BEET checks elsewhere where we check
    whether a given mode is a tunnel or not.

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

    Herbert Xu
     

11 Jul, 2007

1 commit

  • This patch makes MIPv6 loadable module named "mip6".

    Here is a modprobe.conf(5) example to load it automatically
    when user application uses XFRM state for MIPv6:

    alias xfrm-type-10-43 mip6
    alias xfrm-type-10-60 mip6

    Some MIPv6 feature is not included by this modular, however,
    it should not be affected to other features like either IPsec
    or IPv6 with and without the patch.
    We may discuss XFRM, MH (RAW socket) and ancillary data/sockopt
    separately for future work.

    Loadable features:
    * MH receiving check (to send ICMP error back)
    * RO header parsing and building (i.e. RH2 and HAO in DSTOPTS)
    * XFRM policy/state database handling for RO

    These are NOT covered as loadable:
    * Home Address flags and its rule on source address selection
    * XFRM sub policy (depends on its own kernel option)
    * XFRM functions to receive RO as IPv6 extension header
    * MH sending/receiving through raw socket if user application
    opens it (since raw socket allows to do so)
    * RH2 sending as ancillary data
    * RH2 operation with setsockopt(2)

    Signed-off-by: Masahide NAKAMURA
    Signed-off-by: David S. Miller

    Masahide NAKAMURA
     

11 Feb, 2007

1 commit


09 Feb, 2007

1 commit


29 Sep, 2006

1 commit


23 Sep, 2006

8 commits


18 Jun, 2006

1 commit

  • The number of locks used to manage afinfo structures can easily be reduced
    down to one each for policy and state respectively. This is based on the
    observation that the write locks are only held by module insertion/removal
    which are very rare events so there is no need to further differentiate
    between the insertion of modules like ipv6 versus esp6.

    The removal of the read locks in xfrm4_policy.c/xfrm6_policy.c might look
    suspicious at first. However, after you realise that nobody ever takes
    the corresponding write lock you'll feel better :)

    As far as I can gather it's an attempt to guard against the removal of
    the corresponding modules. Since neither module can be unloaded at all
    we can leave it to whoever fixes up IPv6 unloading :)

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

    Herbert Xu
     

14 Jan, 2006

1 commit

  • When the source address of a tunnel is given as 0.0.0.0 do a routing lookup
    to get the real source address for the destination and fill that into the
    acquire message. This allows to specify policies like this:

    spdadd 172.16.128.13/32 172.16.0.0/20 any -P out ipsec
    esp/tunnel/0.0.0.0-x.x.x.x/require;
    spdadd 172.16.0.0/20 172.16.128.13/32 any -P in ipsec
    esp/tunnel/x.x.x.x-0.0.0.0/require;

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     

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