PC-Card Driver and suspend modes

NTDEV
1

Hi,

I have a range of PC-Card devices all supported by a single WDM driver in
Win2K.

The problem is that when the machine comes out of suspend/hibernate I am
unable to talk to the card. The IRP_MJ_POWER function is being handled and
the device power state is being set, however the device still remains
inoperative after a suspend/resume cycle. If the card is unplugged and
re-inserted it works fine.

Does anyone have a good PC-Card sample which includes handling chages in
power states.

Alun Carp
Driver Development Team Leader
Data Encryption Systems Limited

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

>The problem is that when the machine comes out of suspend/hibernate I am

unable to talk to the card. The IRP_MJ_POWER function is being handled and
the device power state is being set, however the device still remains
inoperative after a suspend/resume cycle. If the card is unplugged and
re-inserted it works fine.

I noticed your company lists data encryption. In my opinion, the CORRECT
response for an encryption PCMCIA card might be to revert to a cold reset
state after power restore. I worked on a encryption card driver that had a
lot of sticky issues about power management. You should talk to your
hardware people about how the card is designed. Crypto cards have a lot of
specific behavior to assure secuity.

An app would send a password to the crypto card, and sometime later the OS
would sleep (possibly hybernating). It was a major security hole if the
crypto card was reactivated without being sent the password again. This
also suggests it was inappropriate for the driver to save the crypto state
before power down, transparently restoring it on power up. The APPLICATION
has to prompt for the password again. The security breach might occur if
you hybernate, and then somebody analyzes the hybernation file to find the
saved crypto password info. Power management, and high quality security are
not exactly compatible.

One option was to make the driver fake a card remove/install notification
if it went through a sleep/power up cycle, fooling applications into
thinking the card was physically removed/inserted. Seems like I did this on
a smart card driver.

Of course your issue may be totally different, but thought this might be
useful.

  • Jan

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

Jan,

Thanks for the info, the PC-Cards in question are not Crypto cards,
They are simply PC-Card versions of our LPT port dongles. The
Technique you describe however might be worth a shot. Got any sample
code performing to spoofed remove/insert cycle I could take a look at?

Thanks

Alun Carp
Driver Development Team Leader
Data Encryption Systems Limited

-----Original Message-----
From: Jan Bottorff [mailto:xxxxx@pmatrix.com]
Sent: 03 July 2001 22:33
To: NT Developers Interest List
Subject: [ntdev] Re: PC-Card Driver and suspend modes

The problem is that when the machine comes out of suspend/hibernate I
am unable to talk to the card. The IRP_MJ_POWER function is being
handled and the device power state is being set, however the device
still remains inoperative after a suspend/resume cycle. If the card is
unplugged and re-inserted it works fine.

I noticed your company lists data encryption. In my opinion, the CORRECT
response for an encryption PCMCIA card might be to revert to a cold reset
state after power restore. I worked on a encryption card driver that had a
lot of sticky issues about power management. You should talk to your
hardware people about how the card is designed. Crypto cards have a lot of
specific behavior to assure secuity.

An app would send a password to the crypto card, and sometime later the OS
would sleep (possibly hybernating). It was a major security hole if the
crypto card was reactivated without being sent the password again. This
also suggests it was inappropriate for the driver to save the crypto state
before power down, transparently restoring it on power up. The APPLICATION
has to prompt for the password again. The security breach might occur if
you hybernate, and then somebody analyzes the hybernation file to find the
saved crypto password info. Power management, and high quality security are
not exactly compatible.

One option was to make the driver fake a card remove/install notification
if it went through a sleep/power up cycle, fooling applications into
thinking the card was physically removed/inserted. Seems like I did this on
a smart card driver.

Of course your issue may be totally different, but thought this might be
useful.

  • Jan

You are currently subscribed to ntdev as: xxxxx@des.co.uk
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com