netdev - Re: Endianness problem with u32 classifier hash masks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 06 Nov 2007 01:02:49 +0100
From:	Jarek Poplawski <jarkao2@...pl>
To:	hadi@...erus.ca
CC:	Radu Rendec <radu.rendec@...s.ro>, netdev@...r.kernel.org
Subject: Re: Endianness problem with u32 classifier hash masks

jamal wrote, On 11/05/2007 11:27 PM:

> On Mon, 2007-05-11 at 22:06 +0100, Jarek Poplawski wrote:
>> Radu Rendec wrote, On 11/05/2007 06:31 PM:
> 
>>> But still, Jamal, I need more explanations on what you meant by "cutdown
>>> on the conversion in u32_change()". 
> 
> I meant that it didnt seem necessary to me you have to do the conversion
> back and forth of the hmask as you do in the u32_change(). The basis of
> the patch i posted - which is based on yours - is to remove that change.
> If that doesnt work, please just send your patch as is and we can think
> of optimization later.
> 

>>> And, before proceeding, I'd like to

>>> see your reply to Jarek's last email (at 15:49 +0100) about not getting
>>> 0xff in the end.
> 
> On paper i get the same result with the new or old scheme for the bucket selection.
> As i stated on the patch - i never did test the theory.
> 

In Radu's patch all calculations are done with data in host order, and
still only this one transformation on the fast path. In your version orders
are mixed, and this makes a difference. And, since the old scheme gives
wrong result on little endian, I don't get it why you would want it again?
So, with your patch with the same address and mask: 00.00.0f.f0 (host order
on little endian) we have:

on big endian (net and host order):
f0.0f.00.00 >> 4  gives: ff.00.00.00 with lsb: ff
on little endian (net order):
f0.0f.00.00 >> 4  gives: 0f.00.0f.00 then ntohl: 00.0f.00.0f with lsb: 0f
on little endian with Radu's patch (host order):
00.00.0f.f0 >> 4  gives: 00.00.00.ff with lsb: ff

>> Radu, as far as I know Jamal (from reading) he most probably is busy with
>> some conference! 
> 
> I actually have a day job and have to show up and meet TheMan, Jarek;->
> Most of the days at work, i dont have time to look at external email
> account - but you can bet all horses you own i will get back to you
> within a few hours if you CC me on email.

No offence! I've thought Radu gets a bit impatient, and don't know if he
knows about your scientific and international achievements. On the other
hand I can't imagine why anybody would ever like to go out of Canada!
(Btw, in Polish the second meaning of Kanada is something like paradise
or extreme welfare.) And, on the other hand, I'm very honoured, but I'm
a really modest guy, far from this universities' high life here...

> 
>> Since these patches aren't so big I think you could
>> try Jamal's at first, and if it doesn't work, and nothing new from Jamal
>> in the meantime, resend your version. Cutdown in u32_change() seems to
>> add more to the fastpath, but maybe Jamal thinks about something else.
> 
> I mean do most work on slow/config path.
> 

We have hshift & hamask from there.

Cheers,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html