On Sat, 03 Sep 2022 15:05:39 -0400 David W. Hodgins wrote:

On Sat, 03 Sep 2022 14:45:20 -0400, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:

Hi all,

I just tried to prepare an external harddisk by setting a password to
make it safe for travelling.

All other harddisks like (older) Samsung, Western Digital, Hitachi etc.
accept locking / unlocking via password through hdparm commands via USB
(kernel 5.10.46 / x64), but Samsung EVO 870 refuses to do so:

$ hdparm --user-master u --security-set-pass 'newpass' /dev/sdb
security_password: "newpass"

/dev/sdb:
Issuing SECURITY_SET_PASS command, password="newpass", user=user,
mode=high The running kernel lacks CONFIG_IDE_TASK_IOCTL support for
this device.
SECURITY_SET_PASS: Invalid argument

B.t.w., I cannot even remove or overwrite the manufacturer's secret
master password. So, this is a severe security risk since someone could
know it and unlock those drives.

Has anyone already managed to lock / unlock such a drive?

Any idea how to proceed?

Are you using a usb connection? https://sourceforge.net/p/hdparm/support-requests/7/

Regards, Dave Hodgins

Hi,

and, sorry if confusing with new "fork" of this thread :-)

@ Dave:

Thanks for that link. It looks to me as if there has to be a special
kernel, capable of executing this "CONFIG_IDE_TASK_IOCTL" command?

In the document above, it seems, that no one cares about the request for implementing, or taking this functionality back into the kernel again.

This is somehow puzzling me, because in the past, say, 4-6 years, I had a similar issue with mechanical disks, but with nowadays' kernels most of
the drives can be accessed without any trouble.

Has anyone already tried to activate mentioned method in the kernel
sources?

I'd just be happy if it was possible to deactivate or overwrite the
master password, so that I can, at least, use it as an internal drive in
a different notebook.

Thanks a lot,
best regards,

Markus


--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

Markus Robert Kessler <no_reply@dipl-ing-kessler.de> writes:

On Sat, 03 Sep 2022 15:05:39 -0400 David W. Hodgins wrote:

Are you using a usb connection?
https://sourceforge.net/p/hdparm/support-requests/7/

Regards, Dave Hodgins

Hi,

and, sorry if confusing with new "fork" of this thread :-)

Please don’t do that again, it makes it hard to navigate the thread.

@ Dave:

Thanks for that link. It looks to me as if there has to be a special
kernel, capable of executing this "CONFIG_IDE_TASK_IOCTL" command?

This certainly is a red herring; CONFIG_IDE_TASK_IOCTL has not existed
for years and was only relevant to old-style IDE.

--
https://www.greenend.org.uk/rjk/

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: terraraq NNTP server (2:250/1@fidonet)

On Sun, 04 Sep 2022 09:10:17 +0100 Richard Kettlewell wrote:

Markus Robert Kessler <no_reply@dipl-ing-kessler.de> writes:

On Sat, 03 Sep 2022 15:05:39 -0400 David W. Hodgins wrote:

Are you using a usb connection?
https://sourceforge.net/p/hdparm/support-requests/7/

Regards, Dave Hodgins

Hi,

and, sorry if confusing with new "fork" of this thread :-)

Please don’t do that again, it makes it hard to navigate the thread.

@ Dave:

Thanks for that link. It looks to me as if there has to be a special
kernel, capable of executing this "CONFIG_IDE_TASK_IOCTL" command?

This certainly is a red herring; CONFIG_IDE_TASK_IOCTL has not existed
for years and was only relevant to old-style IDE.

According to what I've just seen, quite the opposite seems to apply:

This is not only an alert, all hdparm-related security modifications to
the drive are really failing.

Well, meanwhile I found a Samsung EVO 840 in one of my notebooks. I set
the user password to NULL and took it out. The drive could be accessed
via hdparm through USB easily. No error occured.

Only these new Samsung EVO 870 drives throw above quoted error alert and refuse to do the demanded modification.

Well, maybe Samsung took old code here (why should they do this?).

Anyway, someone managed to activate this method in the kernel?

Best regards,

Markus


--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 04 Sep 2022 08:44:05 +0000 Markus Robert Kessler wrote:

On Sun, 04 Sep 2022 09:10:17 +0100 Richard Kettlewell wrote:

Markus Robert Kessler <no_reply@dipl-ing-kessler.de> writes:

On Sat, 03 Sep 2022 15:05:39 -0400 David W. Hodgins wrote:

Are you using a usb connection?
https://sourceforge.net/p/hdparm/support-requests/7/

Regards, Dave Hodgins

Hi,

and, sorry if confusing with new "fork" of this thread :-)

Please don’t do that again, it makes it hard to navigate the thread.

@ Dave:

Thanks for that link. It looks to me as if there has to be a special
kernel, capable of executing this "CONFIG_IDE_TASK_IOCTL" command?

This certainly is a red herring; CONFIG_IDE_TASK_IOCTL has not existed
for years and was only relevant to old-style IDE.

Hi,

According to what I've just seen, quite the opposite seems to apply:

This is not only an alert, all hdparm-related security modifications to
the drive are really failing.

Here I have to correct myself. I accomplished some more tests, and I
found out, that only one out of 3 USB-to-SATA converters makes trouble.
May this be called a "red herring", yes :-)

It looks like a compatibility issue between the controller and its
firmware, and the kernel and its USB driver.

I have no idea why this is so a widely spread problem, reading about it
over and over. Probably, a huge number of manufacturers of these
converters are not implementing their stuff fully complying with the spec.

Well, meanwhile I found a Samsung EVO 840 in one of my notebooks. I set
the user password to NULL and took it out. The drive could be accessed
via hdparm through USB easily. No error occured.

Only these new Samsung EVO 870 drives throw above quoted error alert and refuse to do the demanded modification.

Again, I have to correct:
I used a fully working adapter from Logilink together with EVO 840, and a not-complying one, also from Logilink with a different serial number (39993001701) which just allows to mount unprotected drives, and which
not even displays HPA info etc, together with EVO 870.

Not surprising that EVO 870 made more trouble than EVO 840 did...

Thanks,
best regards,

Markus


--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 9/4/2022 2:41 AM, Markus Robert Kessler wrote:

On Sat, 03 Sep 2022 15:05:39 -0400 David W. Hodgins wrote:

On Sat, 03 Sep 2022 14:45:20 -0400, Markus Robert Kessler
<no_reply@dipl-ing-kessler.de> wrote:

Hi all,

I just tried to prepare an external harddisk by setting a password to
make it safe for travelling.

All other harddisks like (older) Samsung, Western Digital, Hitachi etc.
accept locking / unlocking via password through hdparm commands via USB
(kernel 5.10.46 / x64), but Samsung EVO 870 refuses to do so:

$ hdparm --user-master u --security-set-pass 'newpass' /dev/sdb
security_password: "newpass"

/dev/sdb:
Issuing SECURITY_SET_PASS command, password="newpass", user=user,
mode=high The running kernel lacks CONFIG_IDE_TASK_IOCTL support for
this device.
SECURITY_SET_PASS: Invalid argument

B.t.w., I cannot even remove or overwrite the manufacturer's secret
master password. So, this is a severe security risk since someone could
know it and unlock those drives.

Has anyone already managed to lock / unlock such a drive?

Any idea how to proceed?

Are you using a usb connection?
https://sourceforge.net/p/hdparm/support-requests/7/

Regards, Dave Hodgins

Hi,

and, sorry if confusing with new "fork" of this thread :-)

@ Dave:

Thanks for that link. It looks to me as if there has to be a special
kernel, capable of executing this "CONFIG_IDE_TASK_IOCTL" command?

In the document above, it seems, that no one cares about the request for implementing, or taking this functionality back into the kernel again.

This is somehow puzzling me, because in the past, say, 4-6 years, I had a similar issue with mechanical disks, but with nowadays' kernels most of
the drives can be accessed without any trouble.

Has anyone already tried to activate mentioned method in the kernel
sources?

I'd just be happy if it was possible to deactivate or overwrite the
master password, so that I can, at least, use it as an internal drive in
a different notebook.

Thanks a lot,
best regards,

Markus

https://serverfault.com/questions/712849/how-to-unlock-an-ssd-disk-with-hdparm

https://www.thomas-krenn.com/en/wiki/Perform_a_SSD_Secure_Erase

Security:
Master password revision code = 65534
supported
not enabled
not locked does being not-frozen, start this timer?
not frozen -------------------------------------------------------+
not expired: security count |
supported: enhanced erase |
2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT. <--+

https://web.archive.org/web/20141115020359/http://ipv5.wordpress.com/2008/04/14/list-of-hard-disk-ata-master-passwords/

X79 ICH10 - booted my Gentoo install, emerged hdparm, hdparm -I /dev/sda, 870 EVO (250GB)

Master password revision code = 65534
supported
not enabled
not locked
frozen <------------------ Intel Motherboard ports are not good for this exercise
not expired: security count
supported: enhanced erase

Next, I installed a Promise Ultra100 IDE card, then
connected a Startech IDE2SAT adapter, plugged adapter
into Samsung 870 EVO SATA 250GB drive. Used two OSes
with no special kernel, got

Master password revision code = 65534
supported
not enabled
not locked
not frozen <------------------ This worked with a JMB363 IDE as well, plus the IDE2SAT adapter
not expired: security count
supported: enhanced erase

[Picture]

https://i.postimg.cc/28jRbJLN/unfrozen.gif

Paul

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 04 Sep 2022 02:41:45 -0400, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:

Thanks for that link. It looks to me as if there has to be a special
kernel, capable of executing this "CONFIG_IDE_TASK_IOCTL" command?
In the document above, it seems, that no one cares about the request for implementing, or taking this functionality back into the kernel again.
This is somehow puzzling me, because in the past, say, 4-6 years, I had a similar issue with mechanical disks, but with nowadays' kernels most of
the drives can be accessed without any trouble.
Has anyone already tried to activate mentioned method in the kernel
sources?
I'd just be happy if it was possible to deactivate or overwrite the
master password, so that I can, at least, use it as an internal drive in
a different notebook.

The "CONFIG_IDE_TASK_IOCTL" suggestion is a misleading part of the error message
due to the age of the code in hdparm.

The problem is that a usb interface to a sata devices filters out the ioctl commands that are not relevant to a usb device.

It's also quite possible that the firmware on the hard drive doesn't implement the processing of the ioctl commands properly, even when using a sata connection
directly to the controller on the motherboard.

Regards, Dave Hodgins

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)