grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 0/2] Have LUKS2 cryptomounts be useable with grub-probe


From: Glenn Washburn
Subject: Re: [PATCH v2 0/2] Have LUKS2 cryptomounts be useable with grub-probe
Date: Thu, 12 May 2022 17:20:38 -0500

Hi Josselin,

Have this on my list of things to circle back to but it got pushed to
the bottom. So sorry about taking so long. Thanks for the submitting
this. This approach seems the most complete of the other patch series
attempting to fix this issue and I'd like to get it merged in in some
form.

On Sat, 11 Dec 2021 13:29:43 +0100
Josselin Poiret <dev@jpoiret.xyz> wrote:

> Glenn Washburn <development@efficientek.com> writes:
> > Its not clear to me, did you test a LUKS2 device with sector size 4096
> > with this change? I believe DM does use 512-byte sectors internally,
> > but it can create block devices that report and use other sector sizes.
> > You can verfiy this by creating a 4096 sector size LUKS2 devices, open
> > it with cryptsetup, and then run "blockdev --getbsz /dev/mapper/<dm name>".
> 
> You're right, blockdev does indeed report 4096.  Here is an updated
> patch that parses the optional sector_size argument from the DM
> parameters, I have checked that it does indeed set the right
> log_sector_size.  I think it worked without it because you can
> technically just read with a lower sector size, but better be safe
> than sorry!

Actually you can't read an encrypted LUKS devices with a lower sector
size. Well, you can partially, but its like every nth sector. However,
I don't think this code every needs to do the decryption itself anyway,
which is the real reason a different sector size still works.

Glenn

> Josselin Poiret (2):
>   devmapper/getroot: Have devmapper recognize LUKS2
>   devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM
>     parameters
> 
>  grub-core/osdep/devmapper/getroot.c | 107 ++++++++++++++++++++++++++--
>  1 file changed, 102 insertions(+), 5 deletions(-)
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]