[Muscle] New Solaris PC/SC-Lite branch added to repository

[Paul Klissner]

On Jul 3, 2008, at 2:39 AM, Ludovic Rousseau wrote:

> Hello Paul,
>
> I just tried to compile the Solaris branch of pcsc-lite.
>
> On Fri, Jun 13, 2008 at 12:01 AM, Paul Klissner
>> Recently Ludovic created a branch in the repository in which to
>> place a new version of PC/SC-Lite (spun off of PC/SC-Lite 1.3.2),
>> which I've been working on for the past year or so, adapting it
>> for increased scalability and security, as previously discussed
>> on this mail list.
>>
>> The overarching objective was to make PC/SC-Lite adaptable to more
>> kinds of environments. My specific task was to ensure that these new
>> abstractions would be compatible with Solaris Trusted Extensions,
>> and with the Sun Ray thin client platform.  Over the course of
>> development, the design evolved from the proposal initially posted
>> to this list.  However, it works now and is being used in production.
>> This code has had exposure, use and feedback from customers,
>> including some larger installations, and has undergone some quality
>> assurance testing. Thus the new code has been proven viable.
>>
>> The new implementation has been checked-in into the following
>> branch and can be browsed and diff'd online:
>>
>> http://svn.debian.org/viewsvn/pcsclite/branches/Solaris/
>>
>> Documentation for this branch is provided in these files:
>>
>> SECURITY_SCALABILITY_ENHANCEMENTS.pdf    Design document
>> README.build                             Build instructions
>> BUGS.txt                                 Issues/TO DO
>>
>>
>> WHAT THIS BRANCH DELIVERS:
>>
>> This workspace currently constructs a Solaris 10 compatible package
>> "SolarisPCSC" for SPARC and i386. That package installs the new
>> PC/SC-lite framework, providing basic components and infrastructure
>> to support using Smart Card readers associated with local consoles
>> (X-Windows) on a UNIX-like system.  It can be extended for other
>> environments by providing additional configuration files and
>> plugins.
>>
>> A package called "SUNWpcscdtu", soon to be on Sun's download center,
>> contains plugins for SolarisPCSC, provisioning PC/SC-Lite to work
>> with Sun Ray thin clients, specifically to use smart card readers
>> internal to Sun Ray desktop units, as well as USB readers connected
>> to them upon installation of the CCID IFD handler.
>>
>> The SUNWpcscdtu package compliments the SUNWpcsc package, which is
>> currently identical to SolarisPCSC.  SUNWpcsc will be posted at
>> Sun's download center, though ultimately we'd rather be working
>> from the open source distribution of PC/SC-Lite; therefore, it is
>> my hope that ultimately these architectural changes will be merged
>> into the trunk to meet the community goals and the needs of users.
>>
>> BACKGROUND:
>>
>> This implementation was designed modularly, with platform neutrality
>> a primary goal.  It was designed to be as flexible and extensible as
>> could be managed, including providing a new plugin interface for
>> user and resource validation and authentication, as well as offering
>> an extensible command-line interface providing backward-compatible
>> modes as well as new operational modes, such as a launcher/instance
>> model.
>>
>> Along the way, a few bugs in in 1.3.2 were found and fixed.  These
>> were discovered by scaling PC/SC-lite for multi-user use and stress
>> testing under a somewhat rigorous test matrix.  Some of these bugs,
>> previously reported to the mail list may have already been fixed
>> in 1.4.x.   The ones that come to mind are a very elusive memory
>> leak, a race condition, a minor incompatibility of  SCardStatus()
>> to the PC/SC spec, and also the way status bits are set in
>> SCardGetStatus().
>
> Do you have a more detailed description of the bugs you corrected?

I'll have to search e-mails and jog my memory.
I know at least two of them (not the SCardStatus one) were
very difficult to find, and only exposed themselves under
high activity and scaling of the infrastructure.

>
>
>> To help people diagnose issues with PC/SC-Lite, a set of tools
>> will be posted this month on Sun's software download center
>> along side the PC/SC-Lite "1.1" distribution.  Among these is a tool
>> that interposes between a client and libpcsclite.so and dereferences
>> arguments and formats and logs transactions.  Another utility allows
>> a reader list to be pruned to nudge client applications to select
>> the proper reader among a plurality, and yet another provides a
>> means to externally induce a regression in SCardStatus() that at
>> least one 3rd party middleware product actually required at one
>> point to function properly.
>
> Are these tools under a free software licence? I think they could be
> used on non Solaris systems.
>
> I do not use the "Sun's software download center". Do you have an URL?
Let me figure out what I can do to make these available.  One of the
tools in that set that I didn't make  public is a stress test suite that
uses plugins.  I'll get back to you soon with info about that.

Apparently the search engine indexing isn't set up properly yet for
the new release, so I'll have to contact the people that handle that
so that the download page comes right up, and then give you a URL.

I also need to see if we have or can get a license to release
the tools to the Open Source community.

>
>
>> NOTES ON MERGING WITH TRUNK:
>>
>> Given deadline pressure and scope of the effort, Solaris-specific
>> code crept in. I suspect a few system calls weren't wrapped in
>> platform-independent abstractions in the manner set forth in 1.3.2,
>> but some are.  It shouldn't take too much work to clean that up.
>
> I attach a patch to make the software compile under Debian GNU/Linux.
> I can't link so I can't run it.

I'll have to check that out!

I was trying to make it build on Linux a couple of weeks ago too.
And the first big problem I ran into is that xdm is required
the way it works now because there is a dependency on the XServers
file.  But since different systems use different display managers
this might require some sort of plugin scheme to abstract it.

>
>
> Comments:
>
> - use #include <stdarg.h> instead of #include <sys/varargs.h>
>
> - #include <sys/param.h> to have MAXPATHLEN defined.
> I don't know if using MAXPATHLEN is a good idea. It is a problem under
> Hurd for example. See
> http://www.debian.org/ports/hurd/hurd-devel-debian.html
>
> - BUILD is not defined anywhere
>
> - ucred.h, synch.h, sys/conf.h, sys/filio.h do not exist on GNU/Linux
>
> - PATH_MAX is redifined in src/auth.c
>
> - macro NONULL() is defined in pcscdaemon.h and also in many .c files
That's a macro I added, right?
Are you saying it should exist, or that it should go elsewhere?
>
>
> - RTLD_PARENT does not exist for GNU/Linux dlopen()
There was some issue on Solaris that caused me to have
to add that flag.  Maybe the default behavior on Linux is
different such that it wouldn't be required.  I don't recall
what the issue was.  I'll have to take some time to re-examine that.
>
>
> - the mutex type is pthread_mutex_t not mutex_t
>
> - use uint32_t instead of uint_t
>
> - gethrtime() is not available
>
> - use SYS_ThreadSelf() instead of thr_self(). And use
> SYS_ThreadEqual() to compare two thread ids.

Thanks.  Those are the kinds of things I anticipated
having to go back and clean up.  I knew about some of them.
The ucred thing is going to require more than just a simple substitution
because the mechanism for getting peer credentials is different on
Linux, BSD, etc...

There's also a dependency on SMF to launch the daemons
that needs to be abstracted out so that another scheme is
used on non-Solaris systems
>
>
>> Beyond ensuring backward-compatibility (autoconf build modes and
>> daemon run modes), and tidying up platform-independent abstractions,
>> I expect that merging the new code with the scores of open source
>> changes made between 1.3.2 and 1.4.x will be the brunt of the
>> unification effort, because there are significant architectural
>> changes in this branch that involve several new source files as well
>> as substantial changes to existing source files. Still, I believe the
>> benefit outweighs the burden.
>
> I also think it a good idea to merge the two branches. But I don't
> know how we should do.

That's great Ludovic.  Really glad you want to do that.
That certainly inspires me to make the effort.

>
>
> One way is to incrementally change the Solaris branch to make it
> compile on GNU/Linux by wrapping Solaris specific code in a portable
> API. This version should still continue to work as expected on
> Solaris.

I agree.  That's what I thought I should start working on to.
>
>
> Then we can try to make it run on GNU/Linux.
>
> Once we have a working code for Solaris and GNU/Linux we can try to
> merge it with the "official" version.

That part I may need some help with.  There have been a lot of
changes and a team cooperation would really make that more feasible.
>
>
>> CONCLUSION:
>>
>> I look forward to discussing this with the community to arrive at
>> a PC/SC-Lite with increased functionality and adaptability that
>> meet the needs of more users.
>
> I haven't seen any comment to you mail in this list. Maybe the
> "community" is not so much interested in your improvements.
>
> I think you/SUN we have to do the most part of the work.

No one has a working example on Linux yet.  The community has no  
experience
with it nor do most probably realize what it does.

Probably not a lot of people have the need for the extra scalability
and security at the moment, and those that do would probably just look
at it and think  - "no distribution available for Linux" and just move  
on.

The problem with Sun doing it is that it is a very substantial effort,
and it's going to take a serious commitment of time and will
to get through it; a project in and of itself,   The changes
to the main branch will not just merge with the new code.  They'll
have to be examined on a case-by-case basis  and some may be irrelevant,
while some changes will require new implementations of sections of code.

When I looked at the diffs since 1.3.2 a few months ago or so I noticed
many mange changes that were syntactical, perhaps whitespace changes.
It's going to be tough just managing the syntax.

The scope change is so substantial that it isn't really a matter of  
saying
that the code would be merged primarily from one code base to the other.
It will probably require drawing from both and building a new one. I  
don't
know the details yet of that, just that it's non-trivial.

Paul