Suspected Bug in DC S3500 Firmware relating to ATA Security Behaviour?

[idata]

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.

[Kevin_M_Intel]

Hi alza,

I understand you are having problems with the security on the SSD so let me help you with that.

The information you have provided is very helpful but I will need to do a research on this and I will be back soon with important information.

Kevin

[Kevin_M_Intel]

Please note that we have tested the ASUS P8Z77-V motherboard and did step by step. This is what we did:

1. We set a password using HDPARM and put the system into Suspend mode.
2. When the system came back out of Suspend mode the drive was locked and I could not access any directories or applications on the drive.
3. We rebooted the system and could not load the OS. The BIOS did not prompt me for the HDD password (I tried on all available SATA ports).
4. W also could not find any way in the BIOS to set or clear the HDD password. Our assumption is that this motherboard does not support HDD passwords.

After that, we tested a different system:

1. We then moved the drive to an Intel DQ87PG board.
2. On power up we were asked for the password as expected. Ubuntu booted properly after supplying the password.
3. We put the system into Suspend mode, waited a few seconds and woke the system up.
4. The drive was NOT locked and the system operated normally.

So at this point, I would like to know what the brand and model of the motherboard is? If this is not Intel®, you may need to confirm if BIOS has support for HDD passwords.

Kevin M

[idata]

Hi Kevin,

Many thanks for your assistance with this.

Your attempts to reproduce the issue, and your subsequent question made me realise I had neglected to provide some key information:

- In my scenario, the drive is used as a data drive only, it is not used as a boot drive; as such the outcome should be independent of whether the motherboard bios supports ATA passwords or not.

- The motherboard in my scenario is the Intel S1200V3RPL. Incidentally, the BIOS on this board doesn't seem to allow the ATA password to be set, but does prompt for the ATA password on a cold or warm boot if

a) the drive already has a password set, and

b) the drive is connected to a port on the motherboard.

- In my scenario however, the drive is connected to a port on an Intel RMS25JB080 controller, and configured in 'pass-through' mode (i.e. not RAID).

- The host os is Fedora 20.

After your tests, I repeated my scenario, but with the drive connected to a port on the motherboard, instead of the RMS25JB080 controller. Unfortunately, I get the same result as before: the drive is locked when waking from sleep, even though it was unlocked before initiating sleep. So, the behaviour I am observing would seem to be independent of the controller the drive is attached to, but is still different to the behaviour you observed with a different Intel board.

Since we are using the same drive, perhaps there is an issue with the S1200V3RPL board or BIOS? Or could it be an os (Fedora vs Ubuntu) issue?

Thanks

Alex.

[Kevin_M_Intel]

Yes I would say that it may be necessary to check for a BIOS update and confirm if the board itself supports HDD password.