From: Nikolai Grigoriev <nikolai@grigr.xyz>
To: Ondrej Kozina <okozina@redhat.com>
Cc: Cryptsetup <cryptsetup@lists.linux.dev>
Subject: Re: OPAL setup for a new drive without sedutil initial setup
Date: Tue, 19 Mar 2024 01:14:32 +0100 (CET) [thread overview]
Message-ID: <NtJ2omI--3-9@grigr.xyz> (raw)
In-Reply-To: <186111b2-f007-4812-8c62-0a8676d9528c@redhat.com>
Hi,
I think I have found it.
It appears to be related to https://github.com/Drive-Trust-Alliance/sedutil/issues/291
Following the recommendation, I have performed the PSID revert. This did not erase any data but the command has completed successfully.
Then I attempted to do cryptsetup again. That still did not work, although the message was different that time - "Incorrect OPAL Admin key". Again, I have entered the OPAL Admin password I wanted to be set.
Then I have realized that I did power down the machine between DriveAliance RESCUE image and Arch Linux installer. So I have downloaded the sedutil-cli official binary and did the same PSID revert again. Then I ran cryptsetup again (cryptsetup --hw-opal-only --type luks2 luksFormat /dev/nvme0n1p3). That command did something for a couple of seconds and then failed with "Cannot setup OPAL segment." error message.
I assumed this error has left the drive in semi-configured state so I did PSID revert one more time. This time the drive did get erased - which mean cryptsetup has at least configured the Admin1 password.
I have recreated my partitions and now performed initialsetup with sedutil. That did work correctly, no errors. Then I retried cryptsetup, now using the actual Admin1 password already set. This command has failed again with the same "Cannot setup OPAL segment" error message.
If I list the locking ranges with sedutil after this failure, it shows 9 (0-8) LRs, none of them is configured. It is clear that it fails somewhere in opal_setup_ranges() function.
Just out of curiosity, I have attempted to set up the locking range manually with sedutil. In my case the start is 786688, the len is 487591936 sectors (sectors are 4k physica/logical). That worked. And I could see LR1 set up correctly. And I was able to lock it.
What I am trying to do is to enable encryption for LVM partition. Just to have EFI and boot partitions unencrypted and everything else encrypted and managed via LVM.
Interestingly enough, when I tried to "eraseLockingRange" with sedutil-cli, I have got the following error: "eraseLockingRange is not implemented. It is not part of the Opal SSC."
cryptsetup debug output seems to suggest that it tries to erase the LR 3 (why 3?? I have only one used + 0 is for entire disk).
----------- debug output -------------------
# cryptsetup 2.7.0 processing "cryptsetup --hw-opal-only --debug luksFormat /dev/nvme0n1p3"
# Verifying parameters for command luksFormat.
# Running command luksFormat.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/nvme0n1p3.
# Trying to open and read device /dev/nvme0n1p3 with direct-io.
# Initialising device-mapper backend library.
# Blkid check (filter none).
WARNING!
========
This will overwrite data on /dev/nvme0n1p3 irrevocably.
Are you sure? (Type 'yes' in capital letters): # Interactive passphrase entry requested.
# Interactive passphrase entry requested.
# Crypto backend (OpenSSL 3.2.1 30 Jan 2024 [default][legacy][threads][argon2]) initialized in cryptsetup library version 2.7.0.
# Detected kernel Linux 6.7.6-arch1-2 x86_64.
# PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
# Formatting device /dev/nvme0n1p3 as type LUKS2 with OPAL HW encryption.
# OPAL GET_STATUS: flags:119
# Reusing open ro fd on device /dev/nvme0n1p3
# OPAL GET_GEOMETRY: align:1, lb_size:4096, gran:8, lowest_lba:0
# OPAL geometry: alignment: 'y', logical block size: 4096, alignment granularity: 8, lowest aligned LBA: 0
# OPAL alignment (4096/8), offset = 0. Required alignment is 1048576.
# Formatting LUKS2 with JSON metadata area 12288 bytes and keyslots area 16744448 bytes.
# Creating new digest 0 (pbkdf2).
# Setting PBKDF2 type key digest 0.
# Running pbkdf2(sha256) benchmark.
# PBKDF benchmark: memory cost = 0, iterations = 4681142, threads = 0 (took 7 ms)
# PBKDF benchmark: memory cost = 0, iterations = 5518821, threads = 0 (took 95 ms)
# PBKDF benchmark: memory cost = 0, iterations = 5433036, threads = 0 (took 772 ms)
# Benchmark returns pbkdf2(sha256) 5433036 iterations, 0 memory, 0 threads (for 256-bits key).
# Segment 0 assigned to digest 0.
# Adding LUKS2 OPAL requirement flag.
# LUKS2 requirements detected:
# opal - known
# LUKS2 requirements detected:
# opal - known
# LUKS2 requirements detected:
# opal - known
# Device size 1997176569856, offset 16777216.
# Wiping LUKS areas (0x000000 - 0x1000000) with zeroes.
# Wiping keyslots area (0x008000 - 0x1000000) with random data.
# Reusing open rw fd on device /dev/nvme0n1p3
# Reusing open ro fd on device /dev/nvme0n1p3
# Acquiring blocking write lock for resource OPAL_259:3.
# Opening lock resource file /run/cryptsetup/LN_OPAL_259:3
# Verifying lock handle for OPAL_259:3.
# WRITE lock for resource OPAL_259:3 taken.
# Reusing open ro fd on device /dev/nvme0n1p3
# Reusing open ro fd on device /dev/nvme0n1p3
# OPAL GET_STATUS: flags:119
# OPAL ERASE_LR: sum:0, who:0, lr:3
# OPAL ERASE_LR failed: not authorized
# Failed to reset (erase) OPAL locking range 3 on device '/dev/nvme0n1p3': not authorized
# OPAL SECURE_ERASE_LR: sum:0, who:0, lr:3
# OPAL SECURE_ERASE_LR failed: not authorized
# Failed to reset (secure erase) OPAL locking range 3 on device '/dev/nvme0n1p3': not authorized
# Unlocking WRITE lock for resource OPAL_259:3.
# Releasing crypt device /dev/nvme0n1p3 context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/nvme0n1p3.
# Closing read write fd for /dev/nvme0n1p3.
Command failed with code -1 (wrong or missing parameters).
------------ end ----------------------------
--
Nikolai Grigoriev
Mar 18, 2024, 09:45 by okozina@redhat.com:
> On 18/03/2024 14:13, Nikolai Grigoriev wrote:
>
>> I tried to enter a password expecting it to become my new Admin1 password. That did not work. The message was something like "Invalid Admin1 password or permission denied". I ran it with "--hw-opal-only" against /dev/nvme0n1p3. The drive us brand-new Crucial T500 2Tb. Never used sedutil on it. I will try sedutil now to see what is going on and to set my password.
>>
> Well, sedutils will ask for the Admin1 pin as well before it can report anything interesting (e.g.: list existing/active locking ranges).
>
> Feel free to open an issue on upstream tracker: https://gitlab.com/cryptsetup/cryptsetup/-/issues, just add --debug parameter in luksFormat command.
>
> Also the device model would be nice to further debug the issue provided it's this very device it does not work with (e.g. "nvme list" command output)
>
> Kind regards
> O.
>
next prev parent reply other threads:[~2024-03-19 0:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 2:21 OPAL setup for a new drive without sedutil initial setup Nikolai Grigoriev
2024-03-18 8:36 ` Ondrej Kozina
[not found] ` <c238a50b-e382-4dec-9b4b-9c33e420b541@redhat.com-NtFh9t5--7-9>
2024-03-18 13:13 ` Nikolai Grigoriev
2024-03-18 13:45 ` Ondrej Kozina
2024-03-19 0:14 ` Nikolai Grigoriev [this message]
[not found] ` <NtJ2omI--3-9@grigr.xyz-NtJ2rJc--N-9>
2024-03-21 21:55 ` Nikolai Grigoriev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=NtJ2omI--3-9@grigr.xyz \
--to=nikolai@grigr.xyz \
--cc=cryptsetup@lists.linux.dev \
--cc=okozina@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).