Re: [PATCH v2 0/2] Improve LUKS2 error reporting

2020-05-30 Thread Patrick Steinhardt
On Fri, Apr 17, 2020 at 03:54:04PM +0200, Daniel Kiper wrote: > On Thu, Apr 16, 2020 at 07:15:06PM +0200, Patrick Steinhardt wrote: > > Hi, > > > > this is the second version of my patch that has the aim of improving > > error reporting for LUKS2 in case decryption of the disk fails. There's > > no

[PATCH 1/4] luks: fix out-of-bounds copy of UUID

2020-05-30 Thread Patrick Steinhardt
When configuring a LUKS disk, we copy over the UUID from the LUKS header into the new `grub_cryptodisk_t` structure via `grub_memcpy ()`. As size we mistakenly use the size of the `grub_cryptodisk_t` UUID field, which is guaranteed to be strictly bigger than the LUKS UUID field we're copying. As a

[PATCH 0/4] Probing support for LUKS2

2020-05-30 Thread Patrick Steinhardt
Hi, while basic LUKS2 support is there already, there is currently no support yet for auto-detection of LUKS2 for of grub-probe, grub-install and companions. As a result, users have to manually configure GRUB to include required modules. This series is a first step towards auto-detection and imple

[PATCH 3/4] luks2: set up dummy sector size during scan

2020-05-30 Thread Patrick Steinhardt
GRUB currently only supports disk sector sizes of at least 9 bits. While not a problem when using decrypted LUKS2 disks, where we configure the sector size after we have decrypted the disk, it will cause failure as soon as we implement support for probing of LUKS2 encrypted disks: we only cheat-mou

[PATCH 2/4] luks2: strip dashes off of the UUID

2020-05-30 Thread Patrick Steinhardt
The UUID header for LUKS2 uses a format with dashes, same as for LUKS(1). But while we strip these dashes for the latter, we don't for the former. This isn't wrong per se, but it's definitely inconsistent for users as they need to use the dashed format for LUKS2 and the non-dashed format for LUKS w

[PATCH 4/4] osdep: detect LUKS2-encrypted devices

2020-05-30 Thread Patrick Steinhardt
While support for LUKS2 has landed already, grub-install(1) doesn't yet detect it as an installation target. Users of grub-install(1) may thus end up with a bootloader that cannot read the encrypted disk, rendering it unusable. As a first step towards auto-detection, this patch implements detectio

[PATCH] pgp: Recognize issuer subpackets in either hashed or unhashed sections

2020-05-30 Thread Charles Duffy
Currently, GRUB's OpenPGP signature parsing searches for the issuer field (specifying the key to use) only in the unhashed portion of the signature. RFC 4880 permits almost all fields (with the sole exception of signature creation time, which MUST be recognized only in the hashed area) to be prese