All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v3 0/9] Cryptodisk fixes for v2.06
@ 2020-09-21  4:54 Glenn Washburn
  0 siblings, 0 replies; 4+ messages in thread
From: Glenn Washburn @ 2020-09-21  4:54 UTC (permalink / raw)
  To: Patrick Steinhardt; +Cc: grub-devel, Denis GNUtoo Carikli, Daniel Kiper

Sep 17, 2020 8:14:40 AM Patrick Steinhardt <ps@pks.im>:

> On Mon, Sep 07, 2020 at 05:27:27PM +0200, Patrick Steinhardt wrote:
>> this is the third version of this patchset, collecting various fixes for
>> LUKS2/cryptodisk for the upcoming release of GRUB v2.06.
>>
>> Besides my Reviewed-by tag, the only thing that changed is the final
>> patch by Glenn. Quoting him:
>>
>>> The main difference with this patch is that sector_size is renamed to
>>> log_sector_size, grub has enough inaccurate or misleading names.
>>> Additionally, rename LOG_SECTOR_SIZE to LUKS_LOG_SECTOR_SIZE and
>>> CRYPT_LOG_SECTOR_SIZE to GRUB_CRYPTODISK_IV_LOG_SIZE and moved to
>>> cryptodisk.h.  Also a comment was reworded for clarity.
>
> A subset of these patches has been applied by Daniel, leaving us at
> (rearranged for better readability):
>
>> Glenn Washburn (6):
>> cryptodisk: Fix incorrect calculation of start sector
>> cryptodisk: Unregister cryptomount command when removing module
>
> Both were picked.
>
>> luks2: Fix use of incorrect index and some error messages
>> luks2: grub_cryptodisk_t->total_length is the max number of device
>> native sectors
>> cryptodisk: Fix cipher IV mode 'plain64' always being set as 'plain'
>> cryptodisk: Properly handle non-512 byte sized sectors
>
> These weren't yet and got some feedback.
>
>> Patrick Steinhardt (3):
>> json: Remove invalid typedef redefinition
>> luks: Fix out-of-bounds copy of UUID
>> luks2: Improve error reporting when decrypting/verifying key
>
> All three of these have been applied.
>
> @Glenn: seeing that all of my patches have been applied, do you want to
> take over your remaining four patches again? That'd probably make the
> process easier for both of us.

Sure, I can do that. I've been traveling for the last several weeks with little connectivity and limited time, which is why I haven't been active in addressing the responses on this thread. Thanks for helping move this forward



^ permalink raw reply	[flat|nested] 4+ messages in thread
* [PATCH 0/9] Cryptodisk fixes for v2.06
@ 2020-08-23 10:59 Patrick Steinhardt
  2020-09-07 15:27 ` [PATCH v3 " Patrick Steinhardt
  0 siblings, 1 reply; 4+ messages in thread
From: Patrick Steinhardt @ 2020-08-23 10:59 UTC (permalink / raw)
  To: grub-devel; +Cc: Denis 'GNUtoo' Carikli, Glenn Washburn, Daniel Kiper

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

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 series and made them play nice with each other.

This patch series shouldn't be applied as-is, but my intention is
instead to bundle all fixes which apply to v2.06 in a single thread to
make discussion easier and help us keep track of what needs to be done.
I've got some comments which I've sent to the original threads already
and added notes below.

- luks2: grub_cryptodisk_t->total_length is the max number of device
  native sectors

    I'm not sure if this fix is correct, mostly because I think that
    `grub_disk_get_size` is buggy already: it returns sectors for
    partitions and the total size for disks. So I do think we need
    another patch to fix that function, too.


- cryptodisk: Incorrect calculation of start sector for grub_disk_read
  in grub_cryptodisk_read

    The patch looks correct to me and matches what both LUKS and LUKS2
    on-disk format say. But I'm surprised our code ever worked correctly
    without this fix, which does make me feel uncomfortable.

- cryptodisk: Properly handle non-512 byte sized sectors

    Should we pick this for v2.06? It definitely fixes things, but also
    feels a bit like feature-enablement.

I've added my Reviewed-by to those patches which look obviously correct
to me.

Glenn, please let me know if this somehow interferes with your work or
if you'd like to handle upstreaming of those fixes yourself.

Patrick


Glenn Washburn (6):
  luks2: Fix use of incorrect index and some error messages
  luks2: grub_cryptodisk_t->total_length is the max number of device
    native sectors
  cryptodisk: Unregister cryptomount command when removing module
  cryptodisk: Incorrect calculation of start sector for grub_disk_read
    in grub_cryptodisk_read
  cryptodisk: Fix cipher IV mode 'plain64' always being set as 'plain'
  cryptodisk: Properly handle non-512 byte sized sectors

Patrick Steinhardt (3):
  json: Remove invalid typedef redefinition
  luks: Fix out-of-bounds copy of UUID
  luks2: Improve error reporting when decrypting/verifying key

 grub-core/disk/cryptodisk.c | 56 +++++++++++++++++++++----------------
 grub-core/disk/luks.c       |  7 +++--
 grub-core/disk/luks2.c      | 33 +++++++++++++---------
 grub-core/lib/json/json.h   |  9 +++---
 include/grub/cryptodisk.h   |  2 +-
 5 files changed, 62 insertions(+), 45 deletions(-)

-- 
2.28.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-09-21  4:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-21  4:54 [PATCH v3 0/9] Cryptodisk fixes for v2.06 Glenn Washburn
  -- strict thread matches above, loose matches on Subject: below --
2020-08-23 10:59 [PATCH " Patrick Steinhardt
2020-09-07 15:27 ` [PATCH v3 " Patrick Steinhardt
2020-09-09 11:28   ` Daniel Kiper
2020-09-17 14:14   ` Patrick Steinhardt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.