IO-Error when trying to change the master password of a self encrypting ssd

[Kevin]

 I tried to set the master password on my self encrypting Samsung SSD 840 Pro in a Dell Latitude 6400 ATG laptop (Bios Version: A34), german keyboard via

sudo hdparm --user-master m --security-set-pass "$( printf 'testmasterpassword' | tr '1234567890qwertzuiopasdfghjklyxcvbnm' '\2-\11\20\21\26\27\30\31\40-\45\60-\70\104-\107\110\111\120')" /dev/sda

this gives me the following error:

security_password=" 1 P01 %011$2" /dev/sda: Issuing SECURITY_SET_PASS command, password=" 1 P01 %011$2", user=master, mode=high SECURITY_SET_PASS: Input/output error

Any idea, whats wrong here? Is there a workaround?

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: hdparm 9.43-1ubuntu1
ProcVersionSignature: Ubuntu 3.8.0-31.46-generic 3.8.13.8
Uname: Linux 3.8.0-31-generic x86_64
ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
Date: Sun Oct 27 20:03:33 2013
InstallationDate: Installed on 2013-10-03 (24 days ago)
InstallationMedia: Lubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423.1)
MarkForUpload: True
SourcePackage: hdparm
UpgradeStatus: No upgrade log present (probably fresh install)

[Seth Arnold (seth-arnold)]

I believe the Linux kernel's default configuration is to filter out these commands (so your webserver doesn't set a password for you :) -- see e.g. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-scsi.c?id=HEAD#n3043

(Though I'm a bit confused, that's in the libata code, and I don't see libata loaded on my laptop...)

Try adding libata.allow_tpm=1 to the kernel command line via's grub edit-command option, and see if this changes the situation.

Thanks

[Tyler Hicks (tyhicks)]

On 2013-10-28 22:46:02, Seth Arnold wrote:
> (Though I'm a bit confused, that's in the libata code, and I don't see
> libata loaded on my laptop...)

It is built in:

$ grep CONFIG_ATA= /boot/config-3.11.0-12-generic
CONFIG_ATA=y
$ cat /sys/module/libata/parameters/allow_tpm
0

[Kevin (kevin999)]

Thanks I will try this. Can I do it from a system running on the disk of which I want to change the master password without danger? If not, should the ssd be locked or unlocked when doing it?

[Seth Arnold (seth-arnold)]

I'm sorry, I don't know the details of the ATA locking mechanism. (I've been content to simply rely upon my BIOS.)

I would personally not try to change the password while a filesystem on the drive is mounted, though I cannot articulate why I would worry about it. If you can umount the filesystem, I would expect that to be sufficient to allow you to change the password. Probably the drive must be unlocked to change the password, that would simplify the design of the drive firmware.

I'm curious, if you learn more, please do report back. :)

Thanks

[Kevin (kevin999)]

I added libata.allow_tpm=1 to the kernel boot options which changed the output of cat /sys/module/libata/parameters/allow_tpm
from 0 to 1 but gave me exactly the same error. I tried this with an updated version of ubuntu (13.10) from a system running on an usb stick. The ssd was unlocked but not mounted. hdparm version: 9.43 and kernel version 3.11.0-12-generic.

[Launchpad Janitor (janitor)]

[Expired for hdparm (Ubuntu) because there has been no activity for 60 days.]