Hi there,
I am trying to evaluate the security features of the DC S3500 SSD, being used as a data drive in a Linux host system.
In particular, I use the hdparm tool to set the ATA user password and master password, and then from a cold boot I use hdparm again to unlock the drive before mounting any filesystem (once the password has been set, the drive will always be in a 'locked' state from a cold boot).
The suspected bug occurs when I use power saving modes on the host system, for example:
1. Cold boot the system (after setting the ATA user password using hdparm)
2. The drive is in a 'locked' state as expected, so it is unlocked using hdparm with the ATA user password.
3. Mount the filesystem.
4. Put the system to sleep (S3 suspend using either the power button with the appropriate systemd configuration, or alternatively the pm-suspend command)
5. Some time later, wake the system from sleep (using the power button)
Expected state of the drive after wake: 'not locked' (since it was 'not locked' before initiating sleep)
Actual state of the drive after wake: 'locked' (and so the previously mounted filesystem will not be accessible!)
This is a problem, since the hdparm tool would have to be used to unlock the drive every time the system wakes from sleep, and the filesystem re-mounted!
For comparison, I changed the steps above slightly so that the system has a warm boot at step 4, instead of sleep. After the warm boot, the state of the drive is 'not locked', as I would expect; this behaviour is different when compared to the behaviour for a sleep-wake cycle, which is why I think that behaviour is a bug (in the firmware perhaps).
Note: I am using the latest firmware, revision 0370 from 11th Feb 2014.
I would be grateful for any comments from Intel engineers on the above; if it is confirmed as a bug, how should I report it formally?
Many thanks
Alex.