We're still trying to come to a conclusion about the most maintainable
approach to getting DRTM implementations like Intel TXT working on UEFI
platforms under Linux. I'm going to try to summarise the situation here
- I'm not an expert, so details may be inaccurate, but I think this is
the
The --target=drive option of the probe command doesn't handle LUKS2
devices:
# dd if=/dev/zero of=data count=10 bs=1M
# losetup --show -f data
/dev/loop4
# echo -n pass | cryptsetup luksFormat -v --type luks2 /dev/loop4
Key slot 0 created.
Command successful.
# echo -n pass |
v2 updates:
* grub-fs-tester: remove extraneous 'sleep' and 'tail'
* add LUKS and LUKS2 fs tests
* the patches have been rebased on top of the master branch
On 09/02/2022 07.20, Glenn Washburn wrote:
> Why do this here instead of leaving this function alone and doing the
> pipe and -C arg
The logical sector size used by LUKS1 is 512 bytes. LUKS2 uses 512 to
4069 bytes.
---
.gitignore | 2 ++
Makefile.util.def| 12 ++
tests/luks2_test.in | 23 ++
tests/luks_test.in | 23 ++
Unlike LUKS1, the sector size of LUKS2 devices isn't hardcoded.
Regarding the probe command, the following values of --target switch
are affected: abstraction, arc_hints, baremetal_hints, bios_hints,
cryptodisk_uuid, drive, efi_hints, hints_string, ieee1275_hints,
zero_check.
For example using
