4 Replies Latest reply on Jul 21, 2015 11:24 AM by jonathan_intel

    730, Linux hdparm & "security level" inconsistencies

    dan74

      Hello

       

      I have a brand new 730 series 480GB SSD (model SSDSC2BP480G4, firmware L2010420) for which I'm trying to set up the master password, the user password and the "maximum" security level using hdparm under Linux.

      I've hit  an unexpected and unexplained problem: after I set the 2 passwords and the security level to "maximum", once I disconnect and reconnect the drive the security level reverts to "high"!

       

      Here's the summary of how it goes, all details are in the attached log file:

      1. Hot plug  the SDD, it gets detected correctly, hdparm -I reports "Master password revision code = 65534", security "supported" but "not enabled"

      2. Set the master password using "hdparm --user-master m --security-set-pass masterpwd /dev/sdb", after this "Master password revision code = 1", security is still "supported" but "not enabled"

      3. Set the user password and the maximum security level using "hdparm --user-master u --security-mode m --security-set-pass userpwd /dev/sdb"; after this "Master password revision code" is still 1, but security becomes "enabled" and "Security level maximum"

      4. Flush caches using "hdparm -f /dev/sdb" and "hdparm -F /dev/sdb"

      5. "Freeze security" using "hdparm --security-freeze /dev/sdb"

      6. Flush caches again using "hdparm -f /dev/sdb" and "hdparm -F /dev/sdb"

      7. At this point "Master password revision code = 1", "security" is "supported", "enabled", "not locked", "frozen" and "Security level maximum"

      8. Cleanly "stop" the SDD using "sync; echo 1 >/sys/block/sdb/device/delete"

      9. Unplug the SDD, wait a few seconds and plug it back in

      10. At this point "Master password revision code = 1", "security" is "supported", "enabled", "locked", "not frozen" but the drive reverted by itself to "Security level high".

      11. Even if the drive reports "Security level high", the master password doesn't seem to unlock it

      12. The user password can unlock the drive (but this was to be expected, regardless of the security level)

       

      As mentioned, all details are in the attached log file.

       

      Please let me know if I'm missing something - I can't see why the device reverts from the maximum security level to "high" and this is driving me nuts. I also have an older device (SSDSC2CW120A3, FwRev=400i) that works correctly (i.e. it stays on the "maximum" security level).

       

      Thank you

      Dan

        • 1. Re: 730, Linux hdparm & "security level" inconsistencies
          jonathan_intel

          Hello Dan74,

           

          As I understand, you are setting Security Level: Maximum, however, after you disconnect and reconnect the SSD, the hdparm -I shows the Security level: high.

          From your description, this appears to be "cosmetic", since the master password does not unlock the SSD as you would expect in high security level. As per definition, when security level is maximum, the master password can Secure Erase the drive, but not unlock it.

          Please let me know if this is correct.

           

          I would like to recommend a few actions that will help us pinpoint possible causes for this:

           

          - Check for BIOS updates for your system.

          - Check for driver/OS updates that may help with the SATA functionality.

           

          - Have you checked if this is displayed like this after doing a full system reboot, instead of just cycling the drive?

          - Have you tested the secure erase capability using the master password? if so, let us know the results.

          - Let us know the OS version, PC model, motherboard model and BIOS, as well as any other information you consider relevant to work on this issue.

          • 2. Re: 730, Linux hdparm & "security level" inconsistencies
            dan74

            Hello jonathan_intel and thank you for the very quick answer

             

            Yes, that is correct - I set the "security level" to "maximum" and it falls back to "high" after the drive is power cycled in any way.

             

            It could very well be "just cosmetic" but I have no way of proving this beyond any doubt (i.e. by exhaustively testing all possible scenarios) and I'm sure you can see how this does undermine confidence. After all, if the drive won't accept the master password to unlock itself, then why would it revert the "security level" from "maximum" to "high"? As per definition, when the security level is "maximum", the user password is the only one that can unlock the drive; however, when the security level is "high", the user password is not the only one that can unlock the drive.

             

            Otherwise, to answer your questions and comments:

             

            1. I checked the same happens on 2 different systems: a desktop PC and a laptop. Both of them are indeed running the latest BIOS versions available (UEFI BIOS for the desktop and regular BIOS for the laptop). However, I find it hard to believe the BIOS version would make any difference for this issue. Please also keep in mind that the older SSD device (SSDSC2CW120A3, FwRev=400i) works as expected on both these systems.

             

            2. I also checked the same happens using 2 different Linux distributions: RIP Linux 13.5 and Fedora 22. While RIP Linux is a bit outdated, the older SSD device (SSDSC2CW120A3, FwRev=400i) still works as expected with it. However, the Fedora version I tested with is the latest one (22), published less than 2 months ago (26 May 2015) and fully updated after installation. The older SSD works perfectly with this Fedora version, too.

             

            3. Yes, I just checked and the same happens even after a full system reboot (with or without power off - it doesn't make any difference).

             

            4. Yes, I just checked the secure erase capability using the master password and it does erase the drive, bringing its security status to "supported" but "not enabled". However, I fail to see how this could be relevant here, as the secure erase was not my primary concern. Otherwise said, the master password is expected to be able to secure erase the drive in both the "high" and "maximum" security modes.

             

             

            OS versions: RIP Linux 13.5 and Fedora 22

            PC model: Gigabyte desktop motherboard (with Intel® Z68 Chipset) and Dell laptop (I can't find the chipset right now but it's most likely from Intel as well, as the CPU is i7-2640M CPU @ 2.80GHz stepping 07)

             

             

            Please advise on how to proceed.

             

            Thank you

            Dan

            • 3. Re: 730, Linux hdparm & "security level" inconsistencies
              jonathan_intel

              Thank you for the new information. Please confirm some details so we can check further on this issue:

               

              1- The issue is that after reboot or SSD is reset, the Security level shows "High", regardless of the level you have configured.

               

              2- When you set the Security level to Maximum, Is the behavior the one you would expect? Meaning, user password unlocks the drive, but master password does not.

               

              3- If you configure Security level High, then there is no problem.

              • 4. Re: 730, Linux hdparm & "security level" inconsistencies
                jonathan_intel

                Also, please let us know the version of HDparm installed in the system.