Re: [RESEND][PATCH] Hop Limit match/target for IPv6

Dear Maciej,

It is a very useful m/t, many thanks for it!
We have got an experimental stub for it in the main module, but
currently unimplemented (in the main module :) ).
BCF the end of the year I have not got enough time to test your m/t (and
drop a mail to Harald). :( (But it looks like a working module.:))
Personally, I have got some problems related the hoplimit target. W/o
IPSec it can be very dangerous in IPv6 networks. (If the auto
configuration is enabled.) But the other hand with this target we can
hide the firewall and check the validity of the management messages.

Many thanks for it!

Regards,

	kisza

--

-- 
    Andras Kis-Szabo       Security Development, Design and Audit
-------------------------/        Zorp, NetFilter and IPv6
 kisza <at> SecurityAudit.hu /------------------------------------------->

[PATCH] sparc64 compatibility netfilter patches

Hi all!

Here are two patches to make netfilter "more" usable on sparc64
platforms with 32-bit user-space.

The first one is a workaround for the not-so-nice idea of passing
a user-space pointer in a structure for setsockopt. The patch makes
the netfilter counters working.

The second one is a workaround for the even-wilder idea of putting
kernel-only variables (including a pointer) into structures used
for communication between user-space and kernel-space, whose sizeof()
is checked at the beginning of the system call. This patch makes
netfilter module "limit" working.

Please review, comment, etc.

Laszlo
email: <valko <at> linux.karinthy.hu>

PS: the first patch is the best I can imagine without changing the way
of data exchange (maybe putting the counters struct at the end of struct
ipt_replace, after the entries, with offset pointers like struct ipt_entry
uses with target_offset and next_offset?), even though it results in
HORRIBLE amount of copying for EVERY iptables change command.
The second is an ugly workaround. The correct way would be to rip off
everything non-user-space from struct ipt_rateinfo, especially these:

        /* Used internally by the kernel */
        unsigned long prev;

Re: [PATCH] sparc64 compatibility netfilter patches

Improved version follows.
Both patches had something to improve.

Laszlo
e-mail: <valko <at> linux.karinthy.hu>

--- linux-2.4.20/arch/sparc64/kernel/sys_sparc32.c	2002-12-09 16:50:51.000000000 +0100
+++ linux-2.4.20-my/arch/sparc64/kernel/sys_sparc32.c	2003-01-01 20:33:05.000000000 +0100
 <at>  <at>  -50,6 +50,7  <at>  <at> 
 #include <linux/icmpv6.h>
 #include <linux/sysctl.h>
 #include <linux/dnotify.h>
+#include <linux/netfilter_ipv4/ip_tables.h>

 #include <asm/types.h>
 #include <asm/ipc.h>
 <at>  <at>  -2777,6 +2778,78  <at>  <at> 
 extern asmlinkage int sys_setsockopt(int fd, int level, int optname,
 				     char *optval, int optlen);

+static int do_netfilter_replace(int fd, int level, int optname,
+				char *optval, int optlen)
+{
+	struct ipt_replace32 {
+		char name[IPT_TABLE_MAXNAMELEN];
+		__u32 valid_hooks;
+		__u32 num_entries;
+		__u32 size;
+		__u32 hook_entry[NF_IP_NUMHOOKS];

Re: [PATCH] sparc64 compatibility netfilter patches

The hack for building the tools is wrong, there are 64-bit
compilers and userspace available.

The real fix for that (for when your tools are 32-bit) is
to run "sparc32 /bin/sh" and compile in that environment.

I'll be looking at the kernel side patch next, it should be
ok.

Re: [Fwd: ACCEPT/DROP]

Hi,

Thomas Heinz wrote:

> You wrote:
> > This may be true for code, but iptables rules describe sets of
> > packets
> 
> This is true for the basic cases only. In general the matches of a
> rule must be considered to be arbitrary packet action (ACCEPT, DROP,
> CONTINUE) returning functions that may even return different actions
> for the same packet. The only constraint for matches is that they
> should work read-only on the packet content, i.e. not modify it.

That's true, as examples one may see the state matches, or the random
match.

Markus

--

-- 
Schabi's Flohmarkt: http://www.uni-ulm.de/~s_mschab/flohmarkt/

Der Dienstweg ist die Verbindung der Sackgasse mit dem Holzweg!
[DoLi in unibwm.studium]

Re: [PATCH] sparc64 compatibility netfilter patches

On Wed, Jan 01, 2003 at 05:16:54PM +0100, Laszlo Valko wrote:
> Hi all!
> 
> Here are two patches to make netfilter "more" usable on sparc64
> platforms with 32-bit user-space.

Thanks a lot for this valuable contribution!

> The first one is a workaround for the not-so-nice idea of passing
> a user-space pointer in a structure for setsockopt. The patch makes
> the netfilter counters working.

Unfortunately we will never get netfilter-specific code into the
sys_sparc32.c file (and we also really don't want it to be there).

Is there no solution which only touches iptables userspace and kernel
code? (net/ipv4/netfilter/* as well as libiptc.c in userspace)?

> Please review, comment, etc.
> 
> Laszlo
> email: <valko <at> linux.karinthy.hu>
> 
> 
> PS: the first patch is the best I can imagine without changing the way
> of data exchange (maybe putting the counters struct at the end of struct
> ipt_replace, after the entries, with offset pointers like struct ipt_entry
> uses with target_offset and next_offset?), even though it results in
> HORRIBLE amount of copying for EVERY iptables change command.

Re: ECN target bug report

On Mon, Dec 09, 2002 at 10:19:06PM +0100, Andrea Rossato wrote:
> attached you will find 3 patches. the first one is an attempt to prove 
> the existence of the problem. 

> the second is just a hack that provides a temporary solution it's just
> a workaround: packets with ec e cwr bits set and good checksum will be
> stripped and checksum recalculated from scratch.

I agree that this is not 

> The problem, as far as I can see it, could be located in csum_partial 
> (arch/i386/lib/checksum.S, meaning a platform dependent problem): i'm 
> not a kernel hacker (i'm a lawyer, a legal scholar actually), but i do 

hey, usually people say IANAL, but you could say IANAP ;)

> not see any mistake in the way partial checksum is carried out in 
> tcp_etc_set. anyway checksum after partial or total recalculation 
> differ. That's a fact. Evidence of the fact  can be gained with the 
> second patch: in this case the kernel will log the checksum after 
> partial recalculation and after total recalculation (that means that two 
> calculations will take place). The two values differ!

It's most certainly not a bug in csum_partial(), since this function is
used all over the place, including other targets like TTL and even the
NAT core itself.

I think there is an error in the way I used the function to recalculate
the TCP checksum.  I'll have a look.

Re: [PATCH] sparc64 compatibility netfilter patches

On Wed, Jan 01, 2003 at 10:22:23PM -0800, David S. Miller wrote:
> 
> The hack for building the tools is wrong, there are 64-bit
> compilers and userspace available.

I totally agree that this hack is the wrong way to do it.
It will definitely not work with 64-bit userspace.

> The real fix for that (for when your tools are 32-bit) is
> to run "sparc32 /bin/sh" and compile in that environment.

I don't see how that would solve our problem. It will probably
produce working code with 64-bit userspace, but not in the mixed
bit-length case.

Actually, the hack with KERNEL_64_USERSPACE_32 in the tools had
existed before I even looked at the code. It was too tempting to
extend it to my case even tough I know it's not good :)

There are basically two "good" and a "worse" solution:

1) make the kernel interface saner by excluding longs and pointers
   altogether, and cleaning it up by separating "interface" and
   "kernel internal" variables/structures (complicated, introducing
   incompatible API changes),

2) do kernel side 32-64 bit conversions (ugly, big performance
   penalty, looks like a big hack, difficult to maintain),

3) make a similar hack, like there currently is, but with correct

Re: [PATCH] sparc64 compatibility netfilter patches

   From: Harald Welte <laforge <at> gnumonks.org>
   Date: Thu, 2 Jan 2003 09:57:34 +0100

   Unfortunately we will never get netfilter-specific code into the
   sys_sparc32.c file (and we also really don't want it to be there).

   Is there no solution which only touches iptables userspace and kernel
   code? (net/ipv4/netfilter/* as well as libiptc.c in userspace)?

It is the only way to translate socket options that include user
pointers or other types that are not identical in the 32-bit
and 64-bit environment.

It is always a bad idea to pass pointers and other non-hardcoded
types (ie. something other than u8, u16 etc.) via APIs.

Re: [PATCH] sparc64 compatibility netfilter patches

On Thu, Jan 02, 2003 at 01:09:53AM -0800, David S. Miller wrote:
>    From: Harald Welte <laforge <at> gnumonks.org>
>    Date: Thu, 2 Jan 2003 09:57:34 +0100
> 
>    Unfortunately we will never get netfilter-specific code into the
>    sys_sparc32.c file (and we also really don't want it to be there).
>    
>    Is there no solution which only touches iptables userspace and kernel
>    code? (net/ipv4/netfilter/* as well as libiptc.c in userspace)?
>    
> It is the only way to translate socket options that include user
> pointers or other types that are not identical in the 32-bit
> and 64-bit environment.
> 
> It is always a bad idea to pass pointers and other non-hardcoded
> types (ie. something other than u8, u16 etc.) via APIs.

Either we change the way of data exchange, or we have to use similar
thunking functions. We could cosmetically beautify it by moving the
actual implementation from sys_sparc32.c into some other source file
(maybe net/ipv4/netfilter/nf_sparc32.c?) and call it from sys_sparc32.c,
this however provides only a maintenance ease. I see that this is
an important aspect, too.

Laszlo
e-mail: <valko <at> linux.karinthy.hu>