Re: ebtables broken for kernel above 2.6.28

Re: ebtables broken for kernel above 2.6.28

[Jan Engelhardt]

On 2009-06-02 12:20:45, Patrick McHardy wrote:
>On Friday 2009-05-29 19:16, Jan Engelhardt wrote:
>>On Friday 2009-05-29 18:20, Bart De Schuymer wrote:
>>>
>>> I think it's best to fix this in the kernel if it's possible,
>>> since we don't want to break compatibility. If the fix has to be
>>> in userspace, then it must be a fix that still works for older
>>> kernels.
>>>
>>> -#define EBT_MIN_ALIGN (__alignof__(struct ebt_entry_target))
>>> +#define EBT_MIN_ALIGN (__alignof__(struct _xt_align))
>>
>>Since the kernel uses xt_align already, it's best for userspace to
>>do the same.
>
>But that doesn't work for older kernels. Please don't dismiss
>compatibility issues that easily. Sometimes things unfortunately do
>slip through, but I expect people to do their best to fix the
>problem properly when this happens.

But if it gets changed back again to ebt_entry_target, it might
stop working for the combinations it currently works on. :/

Re: ebtables broken for kernel above 2.6.28

[Patrick McHardy]

Jan Engelhardt wrote:
> On 2009-06-02 12:20:45, Patrick McHardy wrote:
>   
>> On Friday 2009-05-29 19:16, Jan Engelhardt wrote:
>>     
>>> On Friday 2009-05-29 18:20, Bart De Schuymer wrote:
>>>       
>>>> I think it's best to fix this in the kernel if it's possible,
>>>> since we don't want to break compatibility. If the fix has to be
>>>> in userspace, then it must be a fix that still works for older
>>>> kernels.
>>>>
>>>> -#define EBT_MIN_ALIGN (__alignof__(struct ebt_entry_target))
>>>> +#define EBT_MIN_ALIGN (__alignof__(struct _xt_align))
>>>>         
>>> Since the kernel uses xt_align already, it's best for userspace to
>>> do the same.
>>>       
>> But that doesn't work for older kernels. Please don't dismiss
>> compatibility issues that easily. Sometimes things unfortunately do
>> slip through, but I expect people to do their best to fix the
>> problem properly when this happens.
>>     
>
> But if it gets changed back again to ebt_entry_target, it might
> stop working for the combinations it currently works on. :/
>   

Why, ebtables userspace didn't change, which implies it will still work?

Re: ebtables broken for kernel above 2.6.28

[Jan Engelhardt]

Patrick McHardy wrote on  2009-06-02 12:20:45:
>Jan Engelhardt wrote:
>> On Friday 2009-05-29 18:20, Bart De Schuymer wrote:
>> 
>>> I think it's best to fix this in the kernel if it's possible, since 
>>> we don't
>>> want to break compatibility.
>>> If the fix has to be in userspace, then it must be a fix that still 
>>> works for
>>> older kernels.
>> 
>> Since the kernel uses xt_align already, it's best for userspace to do 
>> the same.
>
>But that doesn't work for older kernels. Please don't dismiss
>compatibility issues that easily. Sometimes things unfortunately
>do slip through, but I expect people to do their best to fix the
>problem properly when this happens.

I compiled myself an ARM crosscompiler, just to see what's going on. Not 
that I could run the binaries, but I could at least look at the objdump 
output. The first impression was: "the state before the supposed 
regression was introduced could not have worked on ARM in the first 
place had I run this".

It turns out that ebtables is completely unusable on at least three 
arches with given ABI configurations even if things were still 
calculated against ebt_replace instead of _xt_align. One case has been 
verified by me since it's consumer hardware, and it surprises me 
the Debian project has not found this earlier, because they actually 
produced one affected binary distribution in the past (x86 with 
k64_u32).

Affected arches are all with k64_u32. (Perhaps almost all — I did not 
recall seeing it on sparc64, and, as I am just checking up on ebtables's 
Makefile, it has a hack for sparc.) The other configuration I see 
problems in is a (rather normal) k32_u32 ARM setup with a kernel 
compiled with CONFIG_EABI=no.

The userspace patch proposed by Sachin Nasap is, IMHO, one to fix the 
alignment problems (both old and recent) in one clap.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables broken for kernel above 2.6.28

[Bart De Schuymer]

Jan Engelhardt schreef:
> Patrick McHardy wrote on  2009-06-02 12:20:45:
>   
>> Jan Engelhardt wrote:
>>     
>>>
>>> Since the kernel uses xt_align already, it's best for userspace to do 
>>> the same.
>>>       
>> But that doesn't work for older kernels. Please don't dismiss
>> compatibility issues that easily. Sometimes things unfortunately
>> do slip through, but I expect people to do their best to fix the
>> problem properly when this happens.
>>     
>
> I compiled myself an ARM crosscompiler, just to see what's going on. Not 
> that I could run the binaries, but I could at least look at the objdump 
> output. The first impression was: "the state before the supposed 
> regression was introduced could not have worked on ARM in the first 
> place had I run this".
>
> It turns out that ebtables is completely unusable on at least three 
> arches with given ABI configurations even if things were still 
> calculated against ebt_replace instead of _xt_align. One case has been 
> verified by me since it's consumer hardware, and it surprises me 
> the Debian project has not found this earlier, because they actually 
> produced one affected binary distribution in the past (x86 with 
> k64_u32).
>
> Affected arches are all with k64_u32. (Perhaps almost all — I did not 
> recall seeing it on sparc64, and, as I am just checking up on ebtables's 
> Makefile, it has a hack for sparc.) The other configuration I see 
> problems in is a (rather normal) k32_u32 ARM setup with a kernel 
> compiled with CONFIG_EABI=no.
>
> The userspace patch proposed by Sachin Nasap is, IMHO, one to fix the 
> alignment problems (both old and recent) in one clap.
>   

Thanks, I'll have a look at it this weekend.

cheers,
Bart

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables broken for kernel above 2.6.28

[sachin sanap]

I have checked it with older and new kernel. The patch to userspace
(ebtables) works fine for me on ARM32. If anyone wants me to do some
more specific testing for the patch let me know.

-Sachin Sanap

On Thu, Jun 18, 2009 at 10:03 PM, Bart De Schuymer<bdschuym@pandora.be> wrote:
> Jan Engelhardt schreef:
>>
>> Patrick McHardy wrote on  2009-06-02 12:20:45:
>>
>>>
>>> Jan Engelhardt wrote:
>>>
>>>>
>>>> Since the kernel uses xt_align already, it's best for userspace to do
>>>> the same.
>>>>
>>>
>>> But that doesn't work for older kernels. Please don't dismiss
>>> compatibility issues that easily. Sometimes things unfortunately
>>> do slip through, but I expect people to do their best to fix the
>>> problem properly when this happens.
>>>
>>
>> I compiled myself an ARM crosscompiler, just to see what's going on. Not
>> that I could run the binaries, but I could at least look at the objdump
>> output. The first impression was: "the state before the supposed regression
>> was introduced could not have worked on ARM in the first place had I run
>> this".
>>
>> It turns out that ebtables is completely unusable on at least three arches
>> with given ABI configurations even if things were still calculated against
>> ebt_replace instead of _xt_align. One case has been verified by me since
>> it's consumer hardware, and it surprises me the Debian project has not found
>> this earlier, because they actually produced one affected binary
>> distribution in the past (x86 with k64_u32).
>>
>> Affected arches are all with k64_u32. (Perhaps almost all — I did not
>> recall seeing it on sparc64, and, as I am just checking up on ebtables's
>> Makefile, it has a hack for sparc.) The other configuration I see problems
>> in is a (rather normal) k32_u32 ARM setup with a kernel compiled with
>> CONFIG_EABI=no.
>>
>> The userspace patch proposed by Sachin Nasap is, IMHO, one to fix the
>> alignment problems (both old and recent) in one clap.
>>
>
> Thanks, I'll have a look at it this weekend.
>
> cheers,
> Bart
>
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables broken for kernel above 2.6.28

[Sachin Sanap]

The ebtables code looks to be inspired by the iptables code. In case
of iptables the IPT_MIN_ALIGN is defined as

#define IPT_MIN_ALIGN (__alignof__(struct ipt_entry))

and in case of ebtables the EBT_MIN_ALIGN is defined as

#define EBT_MIN_ALIGN (__alignof__(struct ebt_entry_target))

So if ebtables fail, iptables should also fail for the same case. But
the differece here clear from the comment in the iptables code

/* ipt_entry has pointers and u_int64_t's in it, so if you align to
   it, you'll also align to any crazy matches and targets someone
   might write */

That might not be the case with ebtables, struct ebt_entry_target.


cheers,
-Sachin Sanap

On Thu, Jun 18, 2009 at 10:03 PM, Bart De Schuymer<bdschuym@pandora.be> wrote:
> Jan Engelhardt schreef:
>>
>> Patrick McHardy wrote on  2009-06-02 12:20:45:
>>
>>>
>>> Jan Engelhardt wrote:
>>>
>>>>
>>>> Since the kernel uses xt_align already, it's best for userspace to do
>>>> the same.
>>>>
>>>
>>> But that doesn't work for older kernels. Please don't dismiss
>>> compatibility issues that easily. Sometimes things unfortunately
>>> do slip through, but I expect people to do their best to fix the
>>> problem properly when this happens.
>>>
>>
>> I compiled myself an ARM crosscompiler, just to see what's going on. Not
>> that I could run the binaries, but I could at least look at the objdump
>> output. The first impression was: "the state before the supposed regression
>> was introduced could not have worked on ARM in the first place had I run
>> this".
>>
>> It turns out that ebtables is completely unusable on at least three arches
>> with given ABI configurations even if things were still calculated against
>> ebt_replace instead of _xt_align. One case has been verified by me since
>> it's consumer hardware, and it surprises me the Debian project has not found
>> this earlier, because they actually produced one affected binary
>> distribution in the past (x86 with k64_u32).
>>
>> Affected arches are all with k64_u32. (Perhaps almost all — I did not
>> recall seeing it on sparc64, and, as I am just checking up on ebtables's
>> Makefile, it has a hack for sparc.) The other configuration I see problems
>> in is a (rather normal) k32_u32 ARM setup with a kernel compiled with
>> CONFIG_EABI=no.
>>
>> The userspace patch proposed by Sachin Nasap is, IMHO, one to fix the
>> alignment problems (both old and recent) in one clap.
>>
>
> Thanks, I'll have a look at it this weekend.
>
> cheers,
> Bart
>
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ebtables broken for kernel above 2.6.28

[Bart De Schuymer]

Bart De Schuymer schreef:
> Jan Engelhardt schreef:
>>
>> The userspace patch proposed by Sachin Nasap is, IMHO, one to fix the 
>> alignment problems (both old and recent) in one clap.
>>   
>
> Thanks, I'll have a look at it this weekend.

I applied the patch and will release a new ebtables version.

cheers,
Bart