sedutil-cli --initialsetup fails with “NOT_AUTHORIZED” on uniniatilized drive when booting with UEFI. #291
Description
Our infrastructure requires that we boot servers with SED via PXE and we unlock the SED in an unattended way. We boot a Linux environment in which we have installed sedutil-cli, we check if the disk has Locked enabled and if not then we configure the SED as per the steps documented here (except for the setup of the PBA as we don’t use it). In some particular cases, it doesn’t work. For the purposes of this issue I will describe some tests we did manually to isolate the problem:
First, we boot in a Linux rescue mode in which we have installed sedutil-cli.
We then run the following command:
sedutil-cli --query /dev/nvme0
In all drives we used to test, part of the output of the above command is this:
Locking function (0x0002)
Locked = N, LockingEnabled = N, LockingSupported = Y, MBRDone = N, MBREnabled = N, MediaEncrypt = Y
We see here that because LockingEnabled is 0, the disk has not been initialized. Then we proceed to run the following command:
sedutil-cli -v --initialsetup test /dev/nvme0n1
We have observed that when booting in Legacy mode for the “Intel SSD DC P4610” and the “Samsung SSD 983 DCT M.2 1” drives, the command works well and the rest of the configuration can be completed. However, when UEFI was used to boot the ““Samsung SSD 983 DCT M.2 1”” drive, running the above command returns this error:
method status code NOT_AUTHORIZED
Session start failed rc = 1
One or more header fields have 0 length
EndSession Failed
takeOwnership failed
Initial setup failed - unable to take ownership
We don’t understand why this is happening, because we know that the disk was not initialized previously and also LockingEnabled is “N”. Switching to boot in Legacy mode makes it work well again.
In our rescue environment, we are installing the sedutil package from the CentOS 7 repositories, which is version 1.15.1-1
Another detail is that if we boot the server in UEFI in rescue mode and remove the configuration using PSID revert, then we can complete the setup (as it was suggested in other issues like #232 and #289). However if the OPAL configuration is removed using "sedutil-cli --revertnoerase
sedutil-cli --reverttper "
then the problem happens again the next time we try to set it up. It seems like when booting in UEFI for some reason it is required to OSID revert before setting up the configuration.
Have you seen this issue before? Are there any pointers you can give us to test it? We are also trying to contact the manufacturer (Samsung) to see if this is something particular of their implementation (we will also try to use disks from another manufacturer to try)
I would like to understand if this is a common issue that happens when booting in UEFI or if it is something typical from this hardware. I'm interested in understanding this because I have to PXE boot a big number of server and apply this configuration to them in an unattended way and it will be difficult (though not impossible) to previously get all the PSIDs of the disks so I can automate running PSID revert previously to the initial setup.