Enable support for ReadOnly locking on Enterprise devices.

[pruiz]

While trying to declara a read-only band on an enterprise-class SED device, we've found sedutil-cli does not (yet) implements support for differentiated readwrite vs read-only locks.

This patch addresses such limitation by implemented the aforementioned feature, so we can use 'sedutil-cli --setLockingRange X RO' on enterprise devices.

Regards

PD: Maybe early drafts of TCG/Enterprise did not support read-only locks, but we've been unable to find any references of such limitation, and existing code was already passing two independent token requests (one for rw, another for ro), albeit both based on the same lock value.

[oom-is]

Is there anyone who can confirm/test this patch? I'd love to include it in the fork I'm curating as it appears both reasonable and straightforward, but I don't have any TCG Enterprise drives with which to test and I'm loath to include changes I can't validate myself (or at least have validated for me.)

[pruiz]

Well, I can. But I am the one publishing the patch. ;)

[pruiz]

Please, note that there are a few other patches/pull-request from mine intended for fixing issues wrt SAS/Enterprise drives.

[oom-is]

Sorry I wasn't clear - I really meant "anyone ELSE". Not that I don't trust contributors, but that I was hoping for confirmation in the form of someone else chiming in with "yes this worked for me".

Also, not sure what your last comment meant - are there specific other TCG Enterprise/Ruby patches that you also want to ensure get included if someone's going to start updating and testing things?

[pruiz]

I was assuming you were asking for someone else (that's why I emphasized the patch was mine ;)), but thought it may be of interest to point out to you that I am still around, just in case.

Wrt other patches, see: #230. This is needed for proper support of (actual) SAS drives attached to SAS controllers (ie. those with drivers not relying on libata).

And on a lesser note: #233. (which is a minor fix for some HGST non-conformant drives).

Right now we are using our own build of sedutil-cli (with the aforementioned patches, along others also posted as pull-request) against a few different models:

• HGST SSD1600MR SSD (HUSMR1680ASS201)
• HGST Ultrastar SS300 SSD (ie. HUSMR3280ASS201)
• HGST Ultrastar HC500 ROTA (ie. HUH721212AL5201)
• HGST SSD400M SSD (sorry, I dont have the P/N around)
• WD Ultrastar DC S530 (WUSTR6480ASS201)

Regards.

[zgap118]

This worked successfully on an EMC rebranded HGST drive. The stock centos version didn't identify these as SED drives.

[root@xxxx GNU-Linux]# ./sedutil-cli --scan
Scanning for Opal compliant disks
/dev/sda     E HUSMM112 CLAR200 C250
/dev/sdb   No  HUC10909 CLAR900 C600
/dev/sdc     E HUSMM118 CLAR800 C250
/dev/sdd     E HUSMM118 CLAR800 C250
/dev/sde   No  HUC10909 CLAR900 C600
/dev/sdf     E HUSMM112 CLAR200 C250
/dev/sdh     E HUSMM118 CLAR800 C250
/dev/sdi     E HUSMM118 CLAR800 C250
/dev/sdj     E HUSMM118 CLAR800 C250
/dev/sdk     E HUSMM118 CLAR800 C250


[root@xxxx GNU-Linux]# ./sedutil-cli --PSIDrevertAdminSP xxxxxxxxxxxxxxxxxx /dev/sdd


revertTper completed successfully`

[kladann]

Hello Pruiz !!!
I'm struggling to get my SED disks recognized on my server. (ubuntu 18.04 - sedutil 1.15.1) The objective of my work is to repurpose SED drives which were removed from an enterprise class machine and make them available (installed) in another similar type machine. (ref: Sedutil SED Enterprise support #337).
Reading thru the above I guess I've found the 1 mi dol answer I'm looking for.

**Right now we are using our own build of sedutil-cli (with the aforementioned patches, along others also posted as pull-request) against a few different models. <<<<

I'd like to ask Pablo Ruiz, how I could get my hands around your mentioned version and give it a try in my environment?
Thanks - Gracias.
bird

[pruiz]

@kladann I do not have built binaries for ubuntu, but you can checkout my branch/pull-request and built it from your self, to give it a try. Regards Pablo

…

On Wed, Oct 21, 2020 at 3:38 PM kladann ***@***.***> wrote: Hello Pruiz !!! I'm struggling to get my SED disks recognized on my server. (ubuntu 18.04 - sedutil 1.15.1) The objective of my work is to repurpose SED drives which were removed from an enterprise class machine and make them available (installed) in another similar type machine. (ref: Sedutil SED Enterprise support #337 <#337> ). Reading thru the above I guess I've found the 1 mi dol answer I'm looking for. **Right now we are using our own build of sedutil-cli (with the aforementioned patches, along others also posted as pull-request) against a few different models. <<<< I'd like to ask Pablo Ruiz, how I could get my hands around your mentioned version and give it a try in my environment? Thanks - Gracias. bird — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#295 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABOV6MDNZVB3YXWH426LJ3SL3P63ANCNFSM4IMC4XGA> .

[colin-stone99]

I test two HGST disks. One is workable and the other is not workable. Pls. see the below:
sysadmin@Test-PowerEdge-R320:~/bin$ sudo sedutil-cli --scan
Scanning for Opal compliant disks
/dev/sda No
/dev/sdb No
/dev/sdc E HUSMM814 CLAR400 C260
/dev/sdd E HUSMM114 CLAR400 C250
/dev/sde E HUSMM814 CLAR400 C260
/dev/sdf E HUSMM114 CLAR400 C250
No more disks present ending scan

in which, HUSMM114CLAR400 (HUSMM1640ASS201 C250 FW) is workable to revert PSID.
But for HUSMM816CLAR400 (HUSMM8040ASS201 C260 FW) was not workable to revert.

sysadmin@Test-PowerEdge-R320:~/bin$ sudo sedutil-cli --revertTPer 2LVY6NBA2LVY6NBA2LVY6NBA2LVY6NBA /dev/sdc
Session Authenticate failed (response = false)

I checked the disk label. The only difference is frist is PSID and second is MSID.
Could you have a double check？

---

I was assuming you were asking for someone else (that's why I emphasized the patch was mine ;)), but thought it may be of interest to point out to you that I am still around, just in case.

Wrt other patches, see: #230. This is needed for proper support of (actual) SAS drives attached to SAS controllers (ie. those with drivers not relying on libata).

And on a lesser note: #233. (which is a minor fix for some HGST non-conformant drives).

Right now we are using our own build of sedutil-cli (with the aforementioned patches, along others also posted as pull-request) against a few different models:

• HGST SSD1600MR SSD (HUSMR1680ASS201)
• HGST Ultrastar SS300 SSD (ie. HUSMR3280ASS201)
• HGST Ultrastar HC500 ROTA (ie. HUH721212AL5201)
• HGST SSD400M SSD (sorry, I dont have the P/N around)
• WD Ultrastar DC S530 (WUSTR6480ASS201)

Regards.

[colin-stone99]

@pruiz Hi, Pruiz

could you help to have a check for the HGST SED disk HUSMM8040ASS201? When I use MSID, it always prompts that Session Authenticate failed (response = false). Thanks very much.