locked
Does 'classify function' (e.g:"classifyFn2") get called in same process context as the process involved in sending/receiving the network traffic RRS feed

  • Question

  • Hi,

    I have a situation where a process A is opening-up a connection to a remote server.
    A process 'B' is about to exit (terminate, handleCount  =0, ReferenceCount:1). 
    Through a DPC, classifyFn( for layer FWPM_LAYER_ALE_CONNECT_REDIRECT_V4) is called in the process context of Process B, while Process A is opening up the connection.
    FWPS_INCOMING_METADATA_VALUES0_  correctly identify Process A. But, PsGetCurrentProcess() returns Process B.

    My questions are:
    1. Do WFP callbacks at different layers for *outgoing* trafic, always orginate through NDIS driver? Refer to frames 28 through 2C
    (I was under the assumptions that it is true only for incoming traffic. I thought outoing traffic gets processed by WFP filters first and then flows through NDIS)
    2. The fact that a callback at layer FWPM_LAYER_ALE_CONNECT_REDIRECT_V4 being called reveals that the role of this end point is *CLIENT* and is opening the connection. Is it true?
    3. Are interrupts involved while sending *outgoing* traffic? (In the below callstack, a VM bus interrupt nt!KiVmbusInterrupt0, is involved. It's a hyper-v VM)
    4. Is the below stack valid? i.e Can WFP callbacks (especially for outgoing traffic/connection) exeucte in a process context that is different from the process that initiated the traffic/connection?


    Thanks in advance!

    0e fffff880`02a2e780 fffff880`01538202 : fffffa80`0c7b5580 fffff880`02a2ea30 fffff880`02a2ea30 fffff880`01b792fc : tcpip!AlePostProcessClassify+0xe9
    0f fffff880`02a2e7d0 fffff880`01518ff9 : 00000000`00000042 fffff880`02a2ed70 fffff880`0200ff02 fffff880`02a2ee40 : NETIO!ProcessCallout+0x15082
    10 fffff880`02a2e940 fffff880`019e3c3e : fffff880`018a1000 fffff880`02a2ee20 00000000`00000000 00000000`00000000 : NETIO!KfdClassify+0x259
    11 fffff880`02a2ed20 fffff880`018ea725 : fffffa80`166587e0 fffffa80`166587e0 fffff880`02a2f7a0 00000000`00000000 : tcpip!AleInspectConnectRequest+0x10208e
    12 fffff880`02a2f510 fffff880`018f32b5 : 00000000`00000000 00000000`00000014 00000000`00000000 fffff801`7fd2dfe3 : tcpip!UdpConnectRedirect+0x15d
    13 fffff880`02a2f680 fffff880`042038d2 : 00000000`00000000 fffffa80`20bd31cc 00000000`0000fffd fffff880`02a2f7f0 : tcpip!UdpIoControlEndpoint+0x1c5
    14 fffff880`02a2f780 fffff880`04203583 : 00000000`8f000001 00000000`00000000 fffffa80`1dd31530 00000000`00000000 : afd!WskProTLControlRequest+0xd2
    15 fffff880`02a2f810 fffff880`04203ba6 : fffffa80`1dd316c0 00000000`8f000001 00000000`00000000 00000000`00000000 : afd!WskProControlSocketCore+0x123
    16 fffff880`02a2f890 fffff880`063a054e : fffffa80`1dd316c0 00000000`00000000 fffffa80`1b77e010 00000000`00000086 : afd!WskProAPIControlSocket+0x96
    17 fffff880`02a2f900 fffff880`0638fedd : 00000000`00000010 fffff880`02a2fa70 fffffa80`1dd316c0 fffffa80`1b77e010 : RtcMRDrv!SocketControl+0xc2
    18 fffff880`02a2f970 fffff880`063a2bbb : fffffa80`20bd3040 fffffa80`225fd010 fffffa80`1b77e010 fffffa80`20bd3040 : RtcMRDrv!RelayConnect+0x2e9
    19 fffff880`02a2fab0 fffff880`063a27bb : fffffa80`1b77e010 fffffa80`0c4a57d0 00000000`00000000 00000000`000007ff : RtcMRDrv!RelayUdpRecvProcessData+0x1eb
    1a fffff880`02a2fbc0 fffff880`0639feba : 00000000`00000000 fffffa80`1b7812e0 fffffa80`0c873100 fffff880`02a2fd00 : RtcMRDrv!RelayWskxEventReceiveFrom+0x1c3
    1b fffff880`02a2fc50 fffff880`04206fd0 : fffffa80`1d1110f0 fffffa80`0cfaa7d0 ffffdbdb`244deb09 fffff880`0147e087 : RtcMRDrv!WskEventReceiveFrom+0x36
    1c fffff880`02a2fc80 fffff880`01923c61 : fffffa80`1d110360 fffffa80`0c873000 fffffa80`0d829eb0 fffffa80`1d110360 : afd!WskProTLEVENTReceiveMessages+0x110
    1d fffff880`02a2fd40 fffff880`0192371f : fffffa80`00000001 fffffa80`00000000 00000000`00000000 fffff880`02a2ff10 : tcpip!UdpDeliverDatagrams+0x241
    1e fffff880`02a2fed0 fffff880`0191fee2 : fffffa80`0cd24830 00000000`00000001 00000000`00000005 00000000`00000000 : tcpip!UdpReceiveDatagrams+0x3e5
    1f fffff880`02a2ffe0 fffff880`01920198 : fffff880`02a30209 00000000`00000011 00000000`00000000 00000000`00000000 : tcpip!IppDeliverListToProtocol+0xf2
    20 fffff880`02a30090 fffff880`0192421b : fffff880`01a32b90 fffff880`01a32b90 00000001`0000006c fffff880`02a301a8 : tcpip!IppProcessDeliverList+0x68
    21 fffff880`02a30140 fffff880`01921c71 : 00000000`00000001 fffffa80`0cd22ac0 00000000`00000000 fffff880`01a32b90 : tcpip!IppReceiveHeaderBatch+0x21b
    22 fffff880`02a30270 fffff880`019230b3 : fffffa80`1bb0b130 00000000`00000000 fffffa80`224b7201 fffff880`02a30501 : tcpip!IpFlcReceivePackets+0x641
    23 fffff880`02a304a0 fffff880`0192e139 : fffffa80`1bb37a01 00000000`00000000 fffff880`01921540 fffff880`00000000 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2ce
    24 fffff880`02a30570 fffff801`7fd42815 : fffffa80`16d49010 fffff801`7fd38af6 00000000`00000000 00000000`00000000 : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0x119
    25 fffff880`02a30670 fffff801`7fd43625 : fffff880`0192e020 fffff880`02a307e0 00000000`00000010 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0xe5
    26 fffff880`02a30770 fffff880`0192e22e : 00000000`00000001 00000000`00000000 fffffa80`0cfaa7d0 fffff880`0141ff4c : nt!KeExpandKernelStackAndCalloutEx+0x25
    27 fffff880`02a307b0 fffff880`0141eb06 : 00000000`03ffbfff fffffa80`0cfaa7d0 fffffa80`1bb39580 fffff880`018f1950 : tcpip!FlReceiveNetBufferListChain+0xae
    28 fffff880`02a30830 fffff880`0141e560 : 00000000`00000002 fffffa80`0cfa0008 fffffa80`0ccd5838 fffffa80`00000001 : NDIS!ndisMIndicateNetBufferListsToOpen+0x126
    29 fffff880`02a308e0 fffff880`0141e843 : 00000000`00000000 00000000`00000000 00000000`00000001 fffffa80`14a9c520 : NDIS!ndisInvokeNextReceiveHandler+0x650
    2a fffff880`02a309b0 fffff880`03c0f629 : fffffa80`0cfaa7d0 00000000`00000000 fffffa80`25db0090 00000000`00000001 : NDIS!NdisMIndicateReceiveNetBufferLists+0xd3
    2b fffff880`02a30a60 fffff880`03c0f3ff : 00000000`00000002 fffffa80`0cfaa9f0 00000000`0000ff02 00000000`00000000 : netvsc63!ReceivePacketMessage+0x169
    2c fffff880`02a30af0 fffff880`00e72844 : 00000000`0000001e 00000000`00000000 fffffa80`0caf60d0 fffffa80`00000040 : netvsc63!NvscKmclProcessPacket+0x23f
    2d fffff880`02a30b60 fffff880`00e7402f : 00000000`00000002 fffff880`00f00002 fffffa80`0caf60d0 fffff880`02a30c40 : vmbkmcl!InpProcessQueue+0x164
    2e fffff880`02a30bf0 fffff880`00e77cb6 : fffffa80`0caf60d0 00000000`00000001 00000000`00000001 fffff801`7fd2dfe3 : vmbkmcl!InpFillAndProcessQueue+0x6f
    2f fffff880`02a30c30 fffff880`00fcd0d7 : fffff880`0331d200 fffff880`02a00180 fffff880`0331d200 00000000`00000000 : vmbkmcl! ?? ::FNODOBFM::`string'+0xb16
    30 fffff880`02a30ca0 fffff801`7fd2c0d8 : fffff880`02a02f00 fffff880`02a30e00 fffff880`00fda3a8 fffff880`01a4fd68 : vmbus!ChildInterruptDpc+0xc7
    31 fffff880`02a30d00 fffff801`7fd282b0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiExecuteAllDpcs+0x198
    32 fffff880`02a30e40 fffff801`7fd27ca5 : 00000000`00000000 fffff880`02a00180 fffff880`0796d630 fffff8a0`12c37c80 : nt!KiRetireDpcList+0xd0
    33 fffff880`02a30fb0 fffff801`7fd27aa9 : fffffa80`1cfb2b00 fffff801`7fde7bad fffff880`02a00180 fffff880`0796d5c0 : nt!KxRetireDpcList+0x5 (TrapFrame @ fffff880`02a30e70)
    34 fffff880`0796d570 fffff801`7fdc2ad5 : 00000000`00000000 fffff801`7fcf8bed 00000000`00000000 00000000`00000000 : nt!KiDispatchInterruptContinue
    35 fffff880`0796d5a0 fffff801`7fcf8bed : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`147dcb00 : nt!KiDpcInterruptBypass+0x25
    36 fffff880`0796d5b0 fffff801`800a8e61 : 00000000`0000003e ffffffff`ffffffff fffffa80`147dcb00 fffff801`800abe1a : nt!KiVmbusInterrupt0+0x20d (TrapFrame @ fffff880`0796d5b0)
    37 fffff880`0796d740 fffff801`800a8b02 : fffffa80`1281c980 00000000`00000000 fffffa80`1281cc68 fffffa80`1281c980 : nt!PspExitProcess+0x81
    38 fffff880`0796d790 fffff801`800d03c1 : fffffa80`1281c950 fffffa80`1281c950 00000000`00086325 fffffa80`14817230 : nt!PspProcessDelete+0x1a2
    39 fffff880`0796d810 fffff801`7fcf6da9 : 00000000`00000000 00000000`00000000 00000000`00086325 fffffa80`1281c980 : nt!ObpRemoveObjectRoutine+0x61

    From the post  "Thread Context of ClassifyFn"

    I see that ClassiFn can get executed in arbitrary thread context, which make the above call stack completely valid. May I know where to find an MSDN url detailing about thread contexts for the WFP callbacks. 

    Appreciate if you any one can share their thoughts on questions 1 and 3. Thanks


    Monday, December 5, 2016 8:44 PM