[#303790] pcscd protocol depends on word size; breaks 32-bit clients with 64-bit server

View Trackers | Bugs | Export CSV

2006-08-27 01:05
Submitted by:
Jeffrey Hutzelman (jhutz-guest)
Assigned to:
Ludovic Rousseau (rousseau)
pcscd protocol depends on word size; breaks 32-bit clients with 64-bit server

Detailed description
The protocol used between libpcsclite and pcscd (src/winscard_msg*) is defined in terms of types which depend on the native word size. This is a problem because there are platforms out there which support running programs with multiple word sizes on the same system. For example, Linux on x86_64. On systems like that, only clients whose word size agrees with that of pcscd will work.

I haven't tried fixing this yet, so I don't know how much of a pain it's going to be. I imagine that doing it right is going to require going to a new protocol version which uses elements of explicitly-defined size, probably the same as those currently used on 32-bit platforms. I'd hope that pcscd would support both the new protocol and the old, word-size-dependent protocol, at least for a while.

I imagine that a similar issue will bite people using Intel-based MacOS boxes, if it hasn't already. Those systems can support binaries with two different byte orders on the same machine. So, when the word size issue is fixed, it might not be a bad idea to switch to using network byte order instead of native at the same time.

Followups: Sort comments antichronologically

Date: 2006-08-27 10:34
Sender: Ludovic Rousseau

connecté user_id=2410You are rigth. I know see why Apple uses explicit sizes in ths pcsc-lite headers files.

What would be the benefit of using the network byte order? The protocol is supposed to be local to a same machine.
Date: 2007-04-09 16:01
Sender: jacob berkman

I've written a patch to address this problem; it is available at:

After some soul-searching, I decided take a route that should have less pain in the long run, at the possible cost of some short-term pain. I decided to change the offending typedefs in wintypes.h to match what their sizes would be on Windows (DWORD in win64 is still 32 bits, as is LONG i believe).

Because this changes the signature of functions and structs, I've bumped the sonumber on the libraries. I thought about only doing this for 64-bit, since this really doesn't change anything for 32-bit, but that seems like more long-term pain that it is worth.

After making this change, I am able to use certificates in a 32-bit mozilla talking to a 64-bit pcscd.
Date: 2007-04-10 07:04
Sender: Ludovic Rousseau

Thanks for the patch.

It is nice but this is an user API change since user code has to be changed to replace some %ld by %d. I don't think I want this.

I was thinking of only changing the communication between libpcsclite and pcscd. I think it should work just by changing the types used in winscard_msg.h
Date: 2007-04-12 18:03
Sender: jacob berkman

Hello Ludovic,

I've done a new patch, changing only the internal wire protocols as you suggest. It was indeed a little bit trickier, but not too difficult.

I've included a "wirecheck" program which will check for changes to the structs that are not word-size compatible. Even thought it is a generated file, pcsc-wirecheck-dist.c should *not* normally be rebuilt; only when you know you are breaking compatibility. We used a similar tool when I worked on Lustre.

I've uploaded the new patch to:

Note that while this patch retains both binary and source compatibility with previous versions, it does break the wire protocol and so pkcs11 modules with forked versions of pcsc-lite (i've run into a couple) will break. I am ok with that.
Date: 2007-05-15 04:21
Sender: Eric Andry


I'm trying to use the x86_64 patch that was posted for theon pcsc-lite-1.4.0 source.

I'm running FC6 x86_64 with kernel 2.6.20-1.2948.fc6

My options for configure:

./configure --libdir=/usr/local/lib64 --enable-usbdropdir=/usr/lib64/pcsc/drivers --enable-daemon --enable-libusb

I've installed and am testing pcscd running as follows:

./pcscd -f -d

All seems to startup and run okay. But when I attempt to use existing
pcsc_scan tool from FC6 package pcsc-tools-1.4.8-1.fc6.x86_64 I get the message:

$ pcsc_scan
PC/SC device scanner
V 1.4.8 (c) 2001-2006, Ludovic Rousseau <>
Compiled with PC/SC lite version: 1.3.1
winscard_clnt.c:416:SCardEstablishContextTH() Your pcscd is too old and does not support CMD_VERSION
SCardEstablishContext: Cannot Connect to Resource Manager 80100013

I also attempted compile pcsc-tools-1.4.8 from source and it also gave the same error message.

I really would like to have the ability to use pcscd with 32-bit clients because
many of the plugins I use (including Citrix) still do not support 64-bit browsers.
Date: 2007-05-15 16:35
Sender: Ludovic Rousseau

I first need to setup a 32/64-bits machine. I do not own one so I have wait until I can access one and test the proposed patch.
Date: 2007-05-15 17:30
Sender: Jeffrey Hutzelman

I can set up a VM for this purpose; contact me directly and we'll work out the details.
Date: 2007-05-15 17:53
Sender: Jeffrey Hutzelman

Hm; I don't think I ever answered this:

> What would be the benefit of using the network byte order?

On machines like intel-based Mac's, you can have software using both byte orders on the same machine. So, a PPC application would not be able to talk to an x86 pcscd, because of the byte order problem.

Incidentally, I was originally OK with making a backward-incompatible change to the wire protocol and requiring people to upgrade pcscd and clients at the same time. However, now that there are Linux distributions which include pcsc-lite and ship both 32- and 64-bit libraries, we're going to start seeing problems like Eric Andry's, where people try to build pcsc-lite from source and it doesn't interop with the vendor's pcscd (or, they install the new one and it doesn't interop with the vendor's apps). It would be nice if we could figure out how to prevent this, at least in the common cases.
Date: 2007-05-15 19:59
Sender: Ludovic Rousseau

> On machines like intel-based Mac's, you can have software using both byte orders on the same machine. So, a PPC application would not be able to talk to an x86 pcscd, because of the byte order problem.

No. The PPC application is _emulated_ using Rosetta. And I hope Rosetta will switch the bytes when needed. The PPC application will not talk directly to pcscd or to libpcsclite.

But I am not sure a PowerPC PC/SC application is supposed to run within Rosetta.
Date: 2007-05-15 22:23
Sender: Jeffrey Hutzelman

Sure, but won't the PPC application also be linked against a PPC version of libpcsclite, which will also be emulated? I can't imagine this working any other way; allowing calls from PPC code to x86 libraries is infeasible except when the emulator completely understands the ABI and thus knows things like which parts of a structure are words that require byte-swapping.

Similarly, the emulator can't know that aboud data structures written to disk or sent over the network or to another process, so it can't convert those, either. So if you want PPC and x86 programs to communicate with each other, the message formats they use need to not depend on the host byte order.

Now, we don't currently support MacOS in our computing environment, so I don't much care if the byte-order issue is addressed or not. But I do think it's a real issue, and if a backward-incompatible protocol change is needed anyway to deal with the word size problem, then it seems like a perfect opportunity to kill two birds with one stone.
Date: 2007-05-16 00:17
Sender: Jeffrey Hutzelman

OK. Given that the protocol major version changes, I think I can see how to make a pcscd that can talk to old 32-bit, old 64-bit and new clients. Once Jabob's patch is stabilized and integrated, I'll work up a patch to add backward-compatibility. Also, XXX has convinced me that it's probably not a big deal if you can't run PPC PC/SC applications within Rosetta.

That just leaves testing. The offer of a 64-bit VM still stands, though I'll have to dig around a bit to find a reader I can use for that. The easiest thing to come up with is probably a cryptoflex e-gate card.
Date: 2007-05-16 01:41
Sender: Eric Andry

Wow that's great that I could start the wheels churning again with this issue!

Seriously, I volunteer to continue to test new patches as you release them. I'm already setup to easily swap out vendor provided 64-bit pcscd daemon with one built from source.

Also in addition to testing with pcsc_scan, I will also be testing with libcoolkey (both 64-bit and 32-bit) and pam_pkcs11 module.

Thank you for your continued awesome work! If I can help let me know.
Date: 2007-05-16 06:11
Sender: Ludovic Rousseau

Jeffrey Hutzelman, please do not wait after Jabob's patch to be integrated. It is best to have a global solution from the beginning.

So, if you can, post here a global patch with every thing working.
Date: 2007-05-28 09:41
Sender: Ludovic Rousseau

I now have access to a 32/64-bits machine (iMac with Core2Duo) but I don't know how to setup the configuration so that I can have 32-bits applications inside my 64-bits distribution (Debian etch).

I have a 32-bits chroot to make tests but the /var/run/ directory is not shared between 32 and 64-bits worlds.

Do you have any documentation on how to setup a system like yours?
Date: 2007-05-28 12:51
Sender: jacob berkman

can you mount --bind /var/run /chroot/var/run ?
(when using chroots, i also usually do /dev and /proc as well)
Date: 2007-05-28 13:07
Sender: Ludovic Rousseau

I can't "mount --bind /var/run /chroot/var/run" since /chroot/var/run contains files for other daemons (ssh for example)

But I can configure pscsc-lite with --enable-ipcdir=/whatever_shared_dir and share this directory in both worlds. Thanks for the idea.
Date: 2007-05-28 17:08
Sender: Eric Andry

You might want to try a distro that's setup to work with mixed 64-bit/32-bit like FC6.

I run FC6 x86_64 kernel on a Dell laptop that has the Core 2 Duo.

It separates 32-bit from 64-bit libs with the structure:




When I wanted to test the 64-bit patched daemon I compiled, targeted, and installed to


and kept the /etc/init.d/pcscd
and /usr/sbin/bin/pcscd

script and binary.

Then I modified the startup script to point to the patched binary rather than the one from the distribution.

Since my last post, I also tried removing all 64-bit pcsc packages and drivers and installed 32-bit daemon, associated tools, ccid, and libcoolkey. The combination x86_64 kernel and 32-bit ccid driver worked with an external keyboard with built-in smart card reader. However the laptop internal reader did not work. I'm not a kernel/C/C++ hacker to understand why the 32-bit ccid driver worked with the keyboard and not the internal reader.

So I'm back to square one with 64-bit pcsc*, ccid, and libcoolkey.

Just let me know when you have a patch you'd like me to test out.
Date: 2007-07-20 21:26
Sender: Thomas Harning

I've tried both patches and they work on AMD64 w/ 32-64 interop...

Has there been any more progress on this bug?
Date: 2007-07-20 21:46
Sender: Jeffrey Hutzelman

You haven't said exactly what Dell laptop you have, but chances are the internal reader didn't work because it's simply not supported. Sufficiently recent machines have an O2Micro reader (USB ID 0b97:7772) which is not supported by the CCID driver today, but will be shortly -- Chaskiel and I worked out what was needed a couple of days ago, and I'll be sending patches as soon as I have a spare moment.

As for other status, I'm not sure. I was going to work up a patch to allow a new server to handle both old and new clients, but simply haven't had a chance -- I've been very busy the last couple of months getting our F7 support ready here, and PC/SC simply hasn't been on the radar (except for getting my new laptop to work :-)). I expect to have some time to spend on this starting the week after next.

I don't know if there are any other issues preventing integration of Jacob's patches. If not, then maybe it's better to do so now than to wait for the backwards-compatibility stuff. That's up to Ludovic.

-- Jeff
Date: 2007-07-23 03:41
Sender: Eric Andry

Mr. Hutzelman,

Your right, I should have said what kind of card reader I am using. My Dell D820 laptop's internal card reader DOES work when I was running FC6 x86_64.

I've upgraded to F7, and the card reader works when using all 32-bit drivers and OS. I knew the support for 64-bit to 32-bit server communication would take a while, so when F7 came out, I opted for 32-bit.
Date: 2007-07-31 17:23
Sender: Thomas Harning

Correction to my previous post about it working w/ 32-64 interop:

Using the 1.4.0 patch, PCSC-Lite mostly works, however it does not work well w/ TokenStatus called from a 32-bit app:
It does not return failure-state when the token is removed.
It does not fill in the ATR.

This was a nasty bug to discover... since I was thinking that it was in my app, rather than PCSC-Lite...
Date: 2007-10-09 15:04
Sender: Ludovic Rousseau

This "bug" should be closes in revision 2635

If you have problems please open a new bug.

Thomas Harning, I can't reproduce your problem.

Attached Files:


Field Old Value Date By
ResolutionAccepted2007-10-09 15:04rousseau
status_idOpen2007-10-09 15:04rousseau
close_date2007-10-09 15:042007-10-09 15:04rousseau
ResolutionNone2006-08-27 10:34rousseau
priority52006-08-27 10:34rousseau
assigned_tonone2006-08-27 10:34rousseau
Powered By FusionForge