ALT Linux Bugzilla – #60828

Краткое описание

В ALT Linux Sisyphus make-initrd с feature luks не использует зарегистрированный systemd-tpm2 token для автоматического открытия LUKS2, если в /etc/crypttab для тома указано none в поле keyfile.

В результате при загрузке initrd не пытается выполнить cryptsetup с LUKS token и сразу переходит к запросу пароля.

При этом:

TPM2 корректно работает;
TPM2 token успешно зарегистрирован в LUKS2;
cryptsetup поддерживает systemd-tpm2 token;
TPM2 plugin присутствует внутри initrd;
ручной запуск cryptsetup --token-only из того же initrd успешно открывает LUKS keyslot.

Проблема находится в логике обработчика:

/usr/share/make-initrd/features/luks/data/lib/uevent/handlers/085-luks
Окружение
ALT Linux Regular Sisyphus
build: 20260806
architecture: x86_64
kernel: 6.18.54-6.18-alt1
systemd: 260.4-alt2
cryptsetup: 2.8.4-alt1
shim: 16.1-alt2
GRUB: 2.14-alt9
Secure Boot: enabled
TPM2: enabled and available

Системный /boot находится на отдельном незашифрованном разделе /dev/nvme0n1p2.

ESP:

/dev/nvme0n1p1

LUKS2:

/dev/nvme0n1p3
UUID=57f93512-8af3-604b-addd-8c1d7d92369a

LUKS содержит Btrfs root/home/swap.

Конфигурация crypttab

Используется стандартная запись:

luks-57f93512-8af3-604b-addd-8c1d7d92369a UUID=57f93512-8af3-604b-addd-8c1d7d92369a none luks

Обычный LUKS пароль находится в keyslot 0.

TPM2 token зарегистрирован в keyslot 1:

systemd-cryptenroll /dev/nvme0n1p3 \
    --tpm2-device=auto \
    --tpm2-pcrs=0,2,4,7

Результат:

New TPM2 token enrolled as key slot 1.

Таким образом, парольный fallback сохраняется.

Что работает корректно

TPM2 обнаруживается системой:

/dev/tpm0
/dev/tpmrm0

Проверка:

systemd-analyze has-tpm2

показывает наличие firmware, driver, system, subsystem и TPM2 libraries.

cryptsetup luksDump показывает:

Keyslot 0
Keyslot 1

Token 0
    type: systemd-tpm2
    keyslots: 1

Также в системе присутствует:

/usr/lib64/cryptsetup/libcryptsetup-token-systemd-tpm2.so
Проблема

ALT make-initrd использует классический uevent-based обработчик:

/usr/lib/uevent/handlers/085-luks

В текущей реализации при:

keyfile=none

происходит:

none
 ↓
/etc/cryptsetup-keys.d/<volume>.key
 ↓
файл отсутствует
 ↓
rc=1
 ↓
запрос пароля

То есть LUKS token не проверяется.

Критический фрагмент исходного обработчика:

else
    message "The keyfile was not found for partition: $LUKS_ROOT"
    rc=1
fi

При этом в initrd уже присутствует TPM2 token plugin, но он не вызывается.

Подтверждение проблемы

После добавления TPM2 plugin в initrd был выполнен тест непосредственно из распакованного initrd.

Внутри initrd присутствовали:

/dev/tpm0
/dev/tpmrm0

и:

/usr/lib64/cryptsetup/libcryptsetup-token-systemd-tpm2.so

Команда:

cryptsetup --token-only --debug \
    open --type luks \
    /dev/nvme0n1p3 \
    initrd-tpm-token-test \
    --test-passphrase

успешно выполнилась:

Trying to load /usr/lib64/cryptsetup/libcryptsetup-token-systemd-tpm2.so.
Token handler systemd-tpm2-1.0 systemd-v260.4 loaded successfully.
Requesting JSON for token 0.
Trying to open keyslot 1 with token 0 (type systemd-tpm2).
Trying to open LUKS2 keyslot 1.
Verifying key from keyslot 1, digest 0.
Key slot 1 unlocked.
Command successful.
RETURN_CODE=0

Таким образом, TPM2 unlock полностью работоспособен уже внутри initrd.

Исправление / workaround

Был изменён обработчик 085-luks:

else
    message "The keyfile was not found for partition: $LUKS_ROOT"
    message "Attempting to unlock using LUKS token..."
    cryptsetup --token-only "$@"
    rc="$?"
fi

Также в feature luks был добавлен TPM2 token plugin:

PUT_FEATURE_PROGS += /usr/lib64/cryptsetup/libcryptsetup-token-systemd-tpm2.so

После пересборки:

make-initrd -k "$(uname -r)"

проверено, что plugin и изменённый 085-luks находятся в итоговом initrd.

После перезагрузки система автоматически открыла LUKS через TPM2 без запроса пароля.

При этом обычный пароль в keyslot 0 остался доступен как fallback.

Ожидаемое поведение

Если в LUKS2 зарегистрирован поддерживаемый token, например:

systemd-tpm2

и в /etc/crypttab указано:

UUID=<LUKS-UUID> none luks

initrd должен попытаться использовать LUKS token перед переходом к интерактивному вводу пароля.

Ожидаемый порядок:

keyfile
  ↓
LUKS token
  ↓
clevis (если используется)
  ↓
password

или другой документированный порядок, согласованный с архитектурой make-initrd.

Предложение

Стоит изменить feature luks так, чтобы отсутствие keyfile при keyfile=none не означало немедленный переход к password prompt.

Желательно:

Проверять доступные LUKS2 tokens через cryptsetup.
Использовать доступный token handler, в частности systemd-tpm2.
Только после неудачи token unlock переходить к существующим механизмам clevis и password fallback.
При необходимости автоматически включать соответствующие token plugins в initrd.

Это позволит штатно использовать TPM2-enrolled LUKS2 volumes с ALT make-initrd без локального патча 085-luks.

Дополнительное замечание

Добавление:

tpm2-device=auto

в /etc/crypttab в данном окружении не является решением: текущий ALT make-initrd/luks parser не поддерживает этот параметр в используемой конфигурации.

Проблема воспроизводится независимо от этого параметра.

Результат

После локального исправления 085-luks:

UEFI Secure Boot
        ↓
GRUB
        ↓
unencrypted /boot
        ↓
ALT initrd
        ↓
systemd-tpm2 cryptsetup token
        ↓
LUKS2 keyslot 1
        ↓
Btrfs root

загрузка выполняется полностью автоматически, без ввода LUKS-пароля.

Обычный LUKS password keyslot при этом сохраняется как резервный способ разблокировки.