On Fri, Jul 31, 2020 at 07:01:48AM -0500, Glenn Washburn wrote:
> The total_length field is named confusingly because length usually
> refers to bytes, whereas in this case its really the total number of
> sectors on the device. Also counter-intuitively, grub_disk_get_size
> returns the total numbe
On Fri, Jul 31, 2020 at 07:01:44AM -0500, Glenn Washburn wrote:
> Here dev is a grub_cryptodisk_t and dev->offset is offset in sectors of size
> native to the cryptodisk device. The sector is correctly transformed into
> native grub sector size, but then added to dev->offset which is not
> transfor
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
Hi,
I've sifted through the mailing list contents of the last few months to
cherry-pick cryptodisk bugfixes which I think should be included in the
v2.06 release. I've found the following 9 patches from Glenn and me
which should probably be included, separated them out from their
respective patch
The C standard does not allow for typedef redefinitions, even if they
map to the same underlying type. In order to avoid including the
"jsmn.h" in "json.h" and thus exposing jsmn's internals, we have exactly
such a forward-declaring typedef in "json.h". If enforcing the GNU99 C
standard, clang may
From: Glenn Washburn
Signed-off-by: Glenn Washburn
Reviewed-by: Patrick Steinhardt
---
grub-core/disk/luks2.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/grub-core/disk/luks2.c b/grub-core/disk/luks2.c
index e3ff7c83d..200f81d3a 100644
--- a/grub-core/dis
While we already set up error messages in both `luks2_verify_key()` and
`luks2_decrypt_key()`, we do not ever print them. This makes it really
hard to discover why a given key actually failed to decrypt a disk.
Improve this by including the error message in the user-visible output.
Signed-off-by:
From: Glenn Washburn
The total_length field is named confusingly because length usually refers to
bytes, whereas in this case its really the total number of sectors on the
device. Also counter-intuitively, grub_disk_get_size returns the total
number of device native sectors sectors. We need to co
From: Glenn Washburn
Signed-off-by: Glenn Washburn
Reviewed-by: Patrick Steinhardt
---
grub-core/disk/cryptodisk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/grub-core/disk/cryptodisk.c b/grub-core/disk/cryptodisk.c
index 1897acc4b..b2c6e9a7d 100644
--- a/grub-core/disk/cryptodisk.c
+
From: Glenn Washburn
Here dev is a grub_cryptodisk_t and dev->offset is offset in sectors of size
native to the cryptodisk device. The sector is correctly transformed into
native grub sector size, but then added to dev->offset which is not
transformed. It would be nice if the type system would he
From: Glenn Washburn
By default, dm-crypt internally uses an IV that corresponds to 512-byte
sectors, even when a larger sector size is specified. What this means is
that when using a larger sector size, the IV is incremented every sector.
However, the amount the IV is incremented is the number o
From: Glenn Washburn
Signed-off-by: Glenn Washburn
Reviewed-by: Patrick Steinhardt
---
grub-core/disk/cryptodisk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/grub-core/disk/cryptodisk.c b/grub-core/disk/cryptodisk.c
index 76ec2d4b9..74ab54eaa 100644
--- a/grub-core
On Sun, 23 Aug 2020 12:59:57 +0200
Patrick Steinhardt wrote:
> 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 guarant
On Sat, 22 Aug 2020 00:25:18 +0200
Denis 'GNUtoo' Carikli wrote:
> On Wed, 19 Aug 2020 13:59:57 -0500
> Glenn Washburn wrote:
>
> > I'm curious, are you using a virtual machine to test grub? If I
> > understand correctly the above, you're using physical machines to
> > test. I'm using qemu and
On Sun, 23 Aug 2020 12:39:03 +0200
Patrick Steinhardt wrote:
> On Fri, Jul 31, 2020 at 07:01:44AM -0500, Glenn Washburn wrote:
> > Here dev is a grub_cryptodisk_t and dev->offset is offset in
> > sectors of size native to the cryptodisk device. The sector is
> > correctly transformed into native
On Sun, Aug 23, 2020 at 11:31:46PM -0500, Glenn Washburn wrote:
> On Sun, 23 Aug 2020 12:39:03 +0200
> Patrick Steinhardt wrote:
>
> > On Fri, Jul 31, 2020 at 07:01:44AM -0500, Glenn Washburn wrote:
> > > Here dev is a grub_cryptodisk_t and dev->offset is offset in
> > > sectors of size native to
On Sun, 23 Aug 2020 12:59:47 +0200
Patrick Steinhardt wrote:
> Hi,
>
> I've sifted through the mailing list contents of the last few months
> to cherry-pick cryptodisk bugfixes which I think should be included
> in the v2.06 release. I've found the following 9 patches from Glenn
> and me which s
Was it intentional to include the old/original version of this patch
which you requested to be changed to make it more readable? There is
an updated patch with subject "[CRYPTO-LUKS v1 18/19] luks2: Fix use of
incorrect index and some error messages.".
Glenn
On Sun, 23 Aug 2020 13:03:07 +0200
Pa
On Mon, Aug 24, 2020 at 01:22:20AM -0500, Glenn Washburn wrote:
> On Sun, 23 Aug 2020 12:59:47 +0200
> Patrick Steinhardt wrote:
>
> > Hi,
> >
> > I've sifted through the mailing list contents of the last few months
> > to cherry-pick cryptodisk bugfixes which I think should be included
> > in t
On Mon, Aug 24, 2020 at 01:30:05AM -0500, Glenn Washburn wrote:
> Was it intentional to include the old/original version of this patch
> which you requested to be changed to make it more readable? There is
> an updated patch with subject "[CRYPTO-LUKS v1 18/19] luks2: Fix use of
> incorrect index
20 matches
Mail list logo
