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.

[idata]

Hi Kevin,

I checked the bios version on my board, and I'd already updated it to the latest available for the S1200V3RPL - version 02.01.0004

As such I'm not sure where to go from here, since my scenario doesn't depend on full support for the HDD password.

I was wondering if you would be able to test my scenario using the same motherboard and bios version?

Thanks,

Alex.

[Kevin_M_Intel]

Hi alza,

We have tested this from my side and this is what I have:

1. The server board S1200V3RPL does not support HDD password at the BIOS level.
2. You can set a ATA password on the HDD when using a Raid Controller Module that supports the ATA password.
3. Use motherboard that supports a TPM model so you can use the ATA password.

You can search for third party software that may have the capability to set ATA HDD passwords but this can spend many performance resources and slow the system.

Kevin M

[idata]

Hi Kevin,

Thanks for the response;

Regarding point 1, support for HDD password at the BIOS level is not relevant in my scenario, since I am not booting from the drive in question.

Regarding point 2, this is also not relevant in my scenario, since although I have attached the drive in question to a RAID controller, it is configured in 'pass-through' mode, so that the hdparm tool can access it directly.

As such, my query regarding the suspected bug in the drive firmware remains; (relating to the expected behaviour when resuming from sleep, when the drive was unlocked before entering sleep).

Would you be able to reproduce my specific scenario, and clarify the expected behaviour from the drive in this case?

Thanks

Alex.

[Kevin_M_Intel]

Hi alza,

I am going to check some more information but in the meantime you can see some feedback provided on other forum:

http://www.tomshardware.com/answers/id-1844588/drive-locked-hdparm-unlock.html http://www.tomshardware.com/answers/id-1844588/drive-locked-hdparm-unlock.html

NOTE: These links are being offered for your convenience and should not be viewed as an endorsement by Intel of the content, products, or services offered there.

Kevin M

[idata]

Hi Kevin,

Did you manage to find any further information regarding this issue?

As an aside, I use a Lenovo Thinkpad W530 laptop for work, which has an Intel 520 SSD. When running Fedora 20 Linux, I noticed that after setting an ATA password on the drive, I am able to sleep and wakeup without any issues (the drive isn't locked when waking from sleep). Because of this finding, I decided to purchase an Intel 520 SSD and attach it to my S1200V3RPL motherboard and repeat the experiment I tried with the DC S3500 SSD.

Unfortunately, with the 520 SSD I purchased (with the latest available firmware), I observed the same behaviour as for the DC S3500 SSD. I suspect the reason that the SSD in the Lenovo doesn't have the same behaviour is because it has a custom Lenovo firmware which doesn't lock the drive when waking from sleep. It seems odd to me that there are different behaviours with respect to security, depending on what firmware is present...

Thanks

Alex.