fixes for ipfw and pf lock ordering issues

From: Christian S.J. Peron (csjp_at_freebsd.org)
Date: 09/25/04

  • Next message: Max Laier: "Re: fixes for ipfw and pf lock ordering issues" 
    Date: Fri, 24 Sep 2004 22:37:54 +0000
To: hackers@freebsd.org

    Good day folks, we need some beta testers

    Currently, those who utilize ucred based firewalling, i.e. firewall
    rules which match based on UID, GID or JAIL ID are subject to lock order
    problems which often results in the system hard locking. (when giant
    is not present ... debug.mpsafenet=1).

    This problem affects all FreeBSD firewalls which implement ucred based
    matching, namely ipfw and pf. The lock order problem exists due to a
    layering violation which occurs when the IP stack attempts to acquire
    locks within lower level stacks such as UDP and TCP.

    Max Laier (mlaier@) and myself have been working together to solve this
    problem. Together we have generated a set of diffs which do the following:

     o Add a pointer to a PCB to pfil_hooks
     o Modify existing pfil_hooks API to handle this extra argument
     o Modify the pf and ipfw firewalls to utilize this extra argument
       so that lookups on local outbound TCP and UDP traffic can
       be deactivated (removing the requirement for holding INP locks,
       which was a primary suspect for these lock ordering issues).
     o Implement a shared locking mechanism for firewall rule chain protection

    The intended results of these changes are:

    1) Remove the lock ordering issues which result in system hard locks
    2) Avoid redundant PCB lookup overhead improving the overall performance
       of ucred based rule sets
    3) Improving network and firewall parallelism, shared locks give the OS
       the ability to run multiple evaluation or rule check activations
       concurrently, which should increase the overall network throughput
       on devices which have ipfw or pf firewalls enabled (regardless
       of whether or not these rules contain ucred based constraints).

    If anyone could help us test these changes that would be great:

    download:
    http://people.freebsd.org/~csjp/inp_pfil_fw_lor_fixes_shared_locks.1096053274.diff

    cd /usr/src/sys
    fetch http://people.freebsd.org/~csjp/inp_pfil_fw_lor_fixes_shared_locks.1096053274.diff
    patch < inp_pfil_fw_lor_fixes_shared_locks.1096053274.diff

    Recompile your kernel and any related pf or ipfw modules
    add some user/group/jail based firewall rules

    Remember, these are pretty beta so ... be gentle :) 

    -- 
Christian S.J. Peron
csjp@FreeBSD.ORG
FreeBSD Committer
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Max Laier: "Re: fixes for ipfw and pf lock ordering issues"

    Relevant Pages

    • Re: Zonealarm / Email
      ... > An IDS which runs on the same box as the spyware and even opens windows ... So for blocking already running malware on the box ID lock is no ... > for a security system if not counterproductive. ... A software firewall will not stop them, ...
      (comp.security.firewalls)
    • [csjp@freebsd.org: fixes for ipfw and pf lock ordering issues]
      ... we need some beta testers ... Currently, those who utilize ucred based firewalling, i.e. firewall ... rules which match based on UID, GID or JAIL ID are subject to lock order ... matching, namely ipfw and pf. ...
      (freebsd-current)
    • Re: Panic on boot with April 16 src (lengthy info attached)
      ... The essential problem of this lock order reversal has to do with the fact that higher network stack layers hold locks over lower network stack layers. ... This is necessary in order to maintain TCP transmission order into the transmission queue between multiple threads operating on the same TCP connection, as if the "transmit and enqueue" operation were non-atomic with respect to the same TCP connection in another thread, quite damaging reordering could take place. ... We directly dispatch the entire outbound network stack from that enqueue point, meaning that the per-TCP connection lock is held over that processing path, including the firewall. ...
      (freebsd-current)
    • Re: Experiencing hangs on SMP box with no console messages given for clues. Details inside.
      ... the following lock messages came up -- I thought it might be related ... If using uid/gid firewall rules, make sure to read the pertinent man ... using a read-copy-replace write semantic with reference conts on the array.. ... previosu users ofthe structure just keep using the one they have ...
      (freebsd-current)
    • Re: Panic on boot with April 16 src (lengthy info attached)
      ... The essential problem of this lock order reversal has to do with the fact that higher network stack layers hold locks over lower network stack layers. ... This is necessary in order to maintain TCP transmission order into the transmission queue between multiple threads operating on the same TCP connection, as if the "transmit and enqueue" operation were non-atomic with respect to the same TCP connection in another thread, quite damaging reordering could take place. ... We directly dispatch the entire outbound network stack from that enqueue point, meaning that the per-TCP connection lock is held over that processing path, including the firewall. ...
      (freebsd-current)