hdparm Security Unlock

hdparm Security Unlock

[Michael Kuron]

Is there a reason why hdparm.mod does not currently support issuing the ATA SECURITY UNLOCK command to a hard drive?

Looking at hdparm.c, the only change required would be adding write support to grub_hdparm_do_ata_cmd() by doing the following. Write support is already present in grub_ahci_readwrite_real() and grub_pata_readwrite().

@@ -66,7 +66,7 @@
 static grub_err_t
 grub_hdparm_do_ata_cmd (grub_ata_t ata, grub_uint8_t cmd,
 			grub_uint8_t features, grub_uint8_t sectors,
-			void * buffer, int size)
+			void * buffer, int size, int write = 0)
 {
   struct grub_disk_ata_pass_through_parms apt;
   grub_memset (&apt, 0, sizeof (apt));
@@ -78,6 +78,7 @@
 
   apt.buffer = buffer;
   apt.size = size;
+  apt.write = write;
 
   if (ata->dev->readwrite (ata, &apt, 0))
     return grub_errno;

With that change, doing a Security Unlock should be possible using

#define GRUB_ATA_CMD_SECURITY_UNLOCK 0xf2
grub_uint16_t buf[256];
strncpy(buf+1, "Password", 32);
grub_hdparm_do_ata_cmd (ata, GRUB_ATA_CMD_SECURITY_UNLOCK, 0, 1, buf, sizeof (buf));

According to the ATA command specification, buf is 512 bytes long. The first byte is set to 0x00 when using the user password and 0x01 when using the master password. The second byte is ignored, and starting from the third byte we have the password string which has a length of 32 characters. According to the spec, the sector field is ignored;  however the Linux tool hdparm sets it to 1, so that's what I did above.

The Linux tool hdparm uses the command-line argument --security-unlock PWD (it doesn't have a single-letter shorthand form), so maybe we could use that here too (assuming the stuff above does actually work).

Regards,
Michael

Re: hdparm Security Unlock

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

On 07.10.2012 16:54, Michael Kuron wrote:

> Is there a reason why hdparm.mod does not currently support issuing the ATA SECURITY UNLOCK command to a hard drive?
> 
> Looking at hdparm.c, the only change required would be adding write support to grub_hdparm_do_ata_cmd() by doing the following. Write support is already present in grub_ahci_readwrite_real() and grub_pata_readwrite().
> 

It's "patches are welcome" situation

> @@ -66,7 +66,7 @@
>  static grub_err_t
>  grub_hdparm_do_ata_cmd (grub_ata_t ata, grub_uint8_t cmd,
>  			grub_uint8_t features, grub_uint8_t sectors,
> -			void * buffer, int size)
> +			void * buffer, int size, int write = 0)
>  {

We don't use "default" arguments.

>    struct grub_disk_ata_pass_through_parms apt;
>    grub_memset (&apt, 0, sizeof (apt));
> @@ -78,6 +78,7 @@
>  
>    apt.buffer = buffer;
>    apt.size = size;
> +  apt.write = write;
>  
>    if (ata->dev->readwrite (ata, &apt, 0))
>      return grub_errno;
> 
> With that change, doing a Security Unlock should be possible using
> 
> #define GRUB_ATA_CMD_SECURITY_UNLOCK 0xf2
> grub_uint16_t buf[256];
> strncpy(buf+1, "Password", 32);
> grub_hdparm_do_ata_cmd (ata, GRUB_ATA_CMD_SECURITY_UNLOCK, 0, 1, buf, sizeof (buf));

We don't have strncpy, only grub_strncpy and where does 32 comes from?

> 
> According to the ATA command specification, buf is 512 bytes long. The first byte is set to 0x00 when using the user password and 0x01 when using the master password. The second byte is ignored, and starting from the third byte we have the password string which has a length of 32 characters. According to the spec, the sector field is ignored;  however the Linux tool hdparm sets it to 1, so that's what I did above.
> 
> The Linux tool hdparm uses the command-line argument --security-unlock PWD (it doesn't have a single-letter shorthand form), so maybe we could use that here too (assuming the stuff above does actually work).
> 

Command line agument is possible but you also need a possibility to
enter the password from keyboard, necessarry functions are already in
crypto.mod. To avoid hdparm depending on crypto.mod it's good to have a
separate command for unlocking, not part of hdparm.

> Regards,
> Michael
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]