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?
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.
Please note that we have tested the ASUS P8Z77-V motherboard and did step by step. This is what we did:
After that, we tested a different system:
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.
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?
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?
We have tested this from my side and this is what I have:
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.
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?
I am going to check some more information but in the meantime you can see some feedback provided on other forum:
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.
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...
Sorry for the delay on coming back to you.
Based on our research and investigation, this motherboard does not support ATA passwords so setting a password on a system that is not designed to support that feature will lead to unexpected results.
We have extensively tested the ATA password feature on our drives and it works correctly on systems that also support ATA passwords.
Ok thanks for investigating, fair enough regarding the lack of support for ATA passwords on the S1200V3RPL board.
Although that leads me to ask, do any of the current Intel server board models officially support the ATA password feature for the onboard SATA ports?
If not, it leads me to ask, how am I able to correctly use the encryption features of the DC S3500 (without having to spend a considerable additional amount of money on an Intel/LSI hardware raid controller, plus additional money for the encryption upgrade key?)
I am really sorry to give bad news on this but we do not have a Server board at this point that support ATA password and the solution for this would be to use the TPM module or use a raid card with support for this feature.