Porting NDIS intermediate driver to Linux

(tanix) writes:
> Rainer Weikusat <> wrote:
>> (tanix) writes:

[tc]


>>This is extensible in form of modules, too, although lesser used,
>>presumably, because of the extraordinarily poor documentation (there
>>is also a tc manpage). This would enable you to attach a so-called
>>'qdisc' (queueing discipline) to an interface which could basically
>>enforce an arbitrary 'communication policy' directly above the device
>>driver itself.
>
> Well, I just started to think what it all means in terms of porting
> the intermediate NDIS driver and it almost cracked my head to even
> think about this.

Assuming that has a remotely sane structure, meaning, there is some
'entry point' the protocol module sitting above it uses to hand over
frames to it and some 'exit point' where frames supposed to be
transmitted again leave it, with 'some processing logic' in between,
it shouldn't be that difficult: Only the entry and exit points need
major adaptions. All of the tc stuff, that is, the qdisc, just
provides a way to hook your code into the network stack such that it
can police traffic. You don't need to care for any of the existing
queueing disciplines except insofar they might be useful as code
examples. Also, there is no reason to use the data channel for control
communication except if that happened to be convenient. A so-called
'character device', basically, a file an application can open to send
data to some kernel code and receive data from it, might be a better
choice.

On 2009-12-30, tanix <> wrote:
> I need to be able to intercept the traffic from any app
> and I need to control which traffic is to be allowed.

Smells like a fine-grained security policy: SELinux.

> it shouldn't be that difficult: Only the entry and exit points need
> major adaptions.

No. The in-memory representation of a packet can also be different a lot.

For instance, in Windows/NDIS it is _discontiguous_ (this is done to allow the protocols to add headers by chaining one more buffer at front).

IIRC in Linux it is not so, the packets are allocated by the lowest level, with the size being calculated at the highest level (to include all headers). So, the packets are contiguous.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

"Maxim S. Shatskih" <> writes:
>> it shouldn't be that difficult: Only the entry and exit points need
>> major adaptions.
>
> No. The in-memory representation of a packet can also be different a
> lot.

Not really, since they necessarily contain data in the same format
somewhere.

> For instance, in Windows/NDIS it is _discontiguous_ (this is done to
> allow the protocols to add headers by chaining one more buffer at
> front).

Haunted by mbufs, I presume. But a single block of memory can be
treated as a list with only one element.

> IIRC in Linux it is not so, the packets are allocated by the lowest
> level, with the size being calculated at the highest level (to
> include all headers).

'packet' is a somewhat ill-defined term in this context. And your
statement cannot possibly ever make any sense in the way you wrote it,
since data is received 'at the highest level' (that would be the
socket interface) and then travels to the lowest (the device
driver). For this to be possible, buffer space must obviously be
allocated before 'the lowest level' is reached. But this is completely
tangential to the original question and while I am willing to try to
help someone even though this is difficult in absence of any details,
I am not willing to hold entry-level lectures on 'Linux networking' to
an audience of people likely unwilling to listen.

> Haunted by mbufs, I presume. But a single block of memory can be
> treated as a list with only one element.

Correct, but not vice versa.

So, old-style Linux code, which treats each packet as contiguous memory area, can be ported to NDIS in an easy way. Backward port is harder, at least if you will not go on with the perf-losing option of flattening all packets.

Anyway: I know that FreeBSD has a framework (IIRC called "ipf") to inject packet filters to the kernel code, which is more or less similar to Vista+ WFP and NDIS6 filters. So, I also expect Linux to have one.

I would suggest the OP to study both _modern_ (not 2.2) Linux mainstream (not exotic and unfashionable in the Linux world) facilities and NDIS6 filtering. Probably it is not a hard task to write the filtering driver portable across the two.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com