[Winpcap-users] Winpcap in Intanium machine

[Gianluca Varenni]

----- Original Message ----- 
From: "Fish" <fish at infidels.org>
To: <winpcap-users at winpcap.org>
Sent: Saturday, October 10, 2009 4:09 PM
Subject: Re: [Winpcap-users] Winpcap in Intanium machine


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gianluca Varenni wrote:
>> Fish wrote:
>> > Forgive me for asking, but WHY does WinPcap *rely* on
>> > unaligned access?!
>>
>> There are a number of reasons for that, but one of them is
>> simply that WinPcap was developed over the years by people
>> (including myself) that were still learning about problems
>> like misaligned access.
>
> Ah. Okay. Sorry. Been there myself. :)
>
>
>> In general there are two reasons for misaligned access in
>> the WinPcap driver:
>>
>> 1. due to an implementation choice, the packets are stored
>> in the ring buffer without any padding, so the header prepended
>> to each packet can start at a non-aligned address. This is
>> what probably causes the crash that the OP is experiencing.
>
> Sounds likely.
>
>
>> This can be changed (by putting padding bytes at the right
>> spots) but requires touching a very critical part of the
>> capture engine (the ring buffer code).
>
> Critical or not, it needs to be done from the sounds of it.

Well, if the code needs to run on Itanium, there are two options: fix the 
ring buffer code by adding padding or use macros for the unaligned access to 
those fields. Being the first option the best one.

>
>
>> 2. when we access the packet contents for filtering, the
>> header fields are inevitably misaligned. In that case the
>> only solution would be using macros when reading the header
>> fields from the packets to avoid misalignment errors on
>> architectures like Itanium (this is exactly what wireshark
>> does).
> Right! That's what we do in our Hercules project as well. [*]
>

As Guy correctly pointed out, it's actually already done in the driver, I 
simply forgot about that...

>
>> Since we decided not to support Itanium, we relied on the
>> fact that unaligned accesses are supported on x86/x64 (the
>> platforms that we support).
>
> I understand. But my point is regardless of whether it works or not it's
> arguably *incorrect* (or at the very least quite inefficient).
>

It's definitely inefficient compared to aligned accesses. But if I remember 
well, I made the choice of not padding the headers because the ring buffer 
code was definitely much easier. If I were implementing the same code now, I 
would put padding.

>
>> I hope this answers your questions.
>
> It does.
>
> But I'm as yet still unconvinced as to the validity of your reasoning 
> behind
> your apparent reluctance to change it. One should not, IMO, be so 
> reluctant
> to change critical code if the situation warrants it (and IMO it does).
>
> Now I understand the decision is ultimately yours to make and that you 
> know
> what your capabilities are as well as what's best for WinPcap, etc. I
> understand all that.

Sorry if I looked stubborn and reluctant in changing the code. It was not my 
intention. It's definitely something that I can work on in the next weeks, 
but it won't be available in the next release of WinPcap (which will be out 
in a week).

>
> I'm just trying to gently convince you otherwise, that's all. :)
>
> You seem to be a very conscientious and skilled developer which I guess is
> why I'm so surprised about your apparent reluctance to properly address 
> this
> issue. I haven't looked at WinPcap's driver code in a long while now but I
> certainly hope this particular piece of code isn't in the gawd-awful messy
> state it was in many years ago. If it still is then I guess I can 
> understand
> your reluctance to change it (house of cards and all that).

WinPcap still contains some spaghetti code here and there, and over the 
years I slowly cleaned it. But as usual, you don't want to touch code that 
works.
However, the ring buffer code is pretty modularized, and can be modified 
without affecting the rest of the driver.

Have a nice day
GV

>
> But if it's in reasonably good shape however then I think you should
> seriously reconsider your decision not to change it.
>
> With that hope in mind I've attached some modified macros that we 
> ourselves
> use in our Hercules project. Today's mainframes, just like Intel and 
> several
> other architectures, can also stand unaligned accesses just fine (except 
> for
> certain very specific privileged instructions of course). Because our
> emulator is designed to be portable however (and thus capable of running 
> on
> pretty much ANY host platform/architecture), we use the attached 
> portability
> macros when accessing any area of emulated storage. (Note: they also
> portably handle host platform endianess issues too and didn't bother
> removing that part even though that's probably not an issue for you).
>
> I hope you find it useful as an example of how you should be able to 
> easily
> accomplish your goal with minimal risk and maximal efficiency/payoff.
>
> Respectfully submitted,
> - -- 
> "Fish" (David B. Trout) - fish at softdevlabs.com
> Fight Spam! Join CAUCE! <http://www.cauce.org/>
> 7 reasons why HTML email is a bad thing
> http://www.georgedillon.com/web/html_email_is_evil.shtml
> PGP key fingerprints:
> DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A
> RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
>
> [*] http://www.turbohercules.com, http://www.hercules-390.org
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.8.0 (Build 2158)
> Charset: us-ascii
>
> wj8DBQFK0RQ3SPXX9MTuPioRAmE8AJ9Z5btaDLR/jtAsKLTXJIkAjBFEgwCg35Dx
> XQ1NQDy9fCr6JXPI9GVo18o=
> =Aksr
> -----END PGP SIGNATURE-----
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users