[Muscle] Discrepancy between doc of SCardTransmit() and IFDHTransmitToICC()

[David L. Markowitz]

Ludovic Rousseau wrote:
> On Thu, Sep 4, 2008 at 11:57 PM, David L. Markowitz <dav at rttrek.com> wrote:
> 
>>I noticed that the available documentation of SCardTransmit() and
>>IFDHTransmitToICC() differ WRT RecvPci.
>>
>>As documented on MSDN and other places, SCardTransmit() has as its fifth
>>argument:
>>
>>         __inout  LPSCARD_IO_REQUEST pioRecvPci
>>
>>This is described as:
>>
>>   pioRecvPci [in, out]
>>
>>   Pointer to the protocol header structure for the instruction, followed
>>   by a buffer in which to receive any returned protocol control information
>>   (PCI) specific to the protocol in use. This parameter can be NULL if no
>>   PCI is returned.
>>
>>OTOH, as documented by the PC/SC workgroup, and in the MUSCLE PC/SC IFD
>>Driver API, IFDHTransmitToICC() has as its seventh arg:
>>
>>       PSCARD_IO_HEADER RecvPci
>>
>>       RecvPci         INOUT   Receive protocol structure
>>
>># RecvPci - contains two structure members
>>
>>   * Protocol - 0, 1, ... 14
>>
>>     T=0 ... T=14
>>
>>   * Length - Not used.
>>
>>Even worse, the CCID IFDH defines IFDHTransmitToICC() this way:
>>
>>PCSC_API RESPONSECODE
>>IFDHTransmitToICC(/*@unused@*/ DWORD Lun, SCARD_IO_HEADER SendPci,
>>       PUCHAR TxBuffer, DWORD TxLength,
>>       PUCHAR RxBuffer, PDWORD RxLength,
>>       /*@unused@*/ PSCARD_IO_HEADER RecvPci)
>>
>>In the function body, RecvPci->Protocol and RecvPci->Length are never set
>>to anything.  SCardTransmit() passes in a temp space struct, and returns
>>it unchanged and unchecked to the caller if a non-NULL was passed in.
>>
>>We have found some middleware that depends on at least RecvPci->Protocol
>>being set.
>>
>>So, should these values be getting set?  Should they match what was passed
>>in
>>as SendPci?  Or is the middleware broken?
> 
> 
> The parameter is documented as IN and OUT. So the value passed by the
> application shall be set to a correct value. The application shall not
> pass random value and expect a correct value in return. So it looks
> like a bug in the application.

This will not make it through pcscd, at least in any version from 1.3.2
to 1.4.3.  Your code in winscard.c, SCardTransmit(), creates an automatic
stack variable, "SCARD_IO_HEADER sRecvPci", and passes its address to
IFDTransmit() without initialization.  Thus, random values (or zeroes
depending on the compiler).  pioRecvPci is definitely *not* being honored
as an IN and OUT.

Whatever is returned in sRecvPci is copied into *pioRecvPci if it's not
a NULL pointer.

> I never needed to use this parameter so my CCID driver does not use it
> and the parameter is marked as unused.

Perhaps instead of fixing this in the IFDH, it should be fixed in pcscd?

> Why the application is using this parameter and what value is it
> expected on return?

It is Safesign 2.3.0 middleware.  Some old code we used to use passed
1 and 8 in *in SendPci* and we returned 1 and 8 *in RecvPci*.  This works.

Pcscd now passes in 0 and 0 (apparently it zeroes out automatic stack
variables in the compiler being used, or they just happened to be 0).
If RecvPci contains 0 and 0 upon return the middleware fails.

In all likelyhood, it's the Protocol that matters, not the Length.

> PS: I just upgraded the Doxygen documentation of the PCI parameter. I
> will regenerate the HTML pages and update the web site soon. Thanks
> for pointing the problem.

Thanks.

-- 
     David L. Markowitz
     dav at rttrek.com