On Tue, 01 Feb 2022 15:48:01 +0000 Maxim Fomin <ma...@fomin.one> wrote:
> ------- Original Message ------- > > On Monday, January 31st, 2022 at 23:40, Glenn Washburn > <developm...@efficientek.com> wrote: > > > On Sun, 30 Jan 2022 19:40:37 +0000 > > > > Maxim Fomin ma...@fomin.one wrote: > > > > > This patch adds support for plain encryption mode (plain dm-crypt) via new > > > > > > module/command named 'plainmount'. This is an extension of previous patch > > > > > > (member of crypto enhancement patch series) sent to grub-devel by John > > > Lane. > > > > > > The plain mode patch was fully reworked, the most important changes are: > > > > > > 1. The code is rewritten as a separate 'plainmount' module and command. > > > This > > > > > > change addresses several issues raised in previous patch discussion: > > > complex > > > > > > implementation and expanding too much cryptomount parameter list. > > > Plainmount > > > > > > module still depends on several functions in cryptodisk module just > > > like LUKS, > > > > > > LUKS2 and geli modules. I tried to minimize link to cryptodisk, but > > > some link > > > > > > is unavoidable. > > > > > > 2. Plainmount now uses GPT partition unique UUID to point to exact > > > partition. > > > > > > Plain mode does not have special header (as LUKS/LUKS2 does), so it > > > does not > > > > > > have any UUID. Absence of UUID was key issue in discussions of > > > original plain > > > > > > mode patch - without UUID any link like 'hdX,gptY' in grub.cfg can be > > > broken > > > > > > in multiboot setup because hdX can map to different disks each boot. > > > > > > > So plain mount can only be used for volumes located on GPT partitions, > > > > leaving out MBR or any other partitioning format, full-disk encryption, > > > > and loopback file encryption. I think this is an undesirable and > > > > unnecessary limitation. > > > > Instead, I suggest assuming the user knows what they are doing in the > > > > GRUB shell/script and letting them do it. This should not be allowed > > > > when automatically generating the grub.cfg using GRUB user-space tools. > > > > GRUB should fail to automagically install to a device hosted on a plain > > > > encrypted container (unless perhaps an override is given). I suspect > > > > that this is the default, but worth mentioning. > > > > Glenn > > Plainmount can work with '(hdX,gptY)' syntax in config or shell (actually, > this > is the base syntax) and thus it is not limited to GPT paritions, what is > limited > is the ability to use UUID - currently only on GPT. If partition scheme does > not > have UUID then UUID as a convenience feature cannot be supported - > inconvenient, > but technically fair. I will take a look at MBR UUID and see whether they can > be > supported. Possible situations (under current implementaion) are follows: > > a) GPT disk, multi-disk environment, disks map unpredictably: can name > partitions > by GPT UUID in config file/shell, no problem, ability to name by UUID has > value I agree that searching by partition UUID is useful and desirable. However, I don't think this is the right approach. GRUB should have generic searching by partition UUID. There is already a patch for this[1]. Perhaps you can test/review this patch to help it gain more visibility and advocate for it being accepted. Glenn [1] https://lists.gnu.org/archive/html/grub-devel/2021-04/msg00055.html > b) GPT disk, single disk environment: no problem, UUID feature has less value > b) not GPT, single disk environment: no problem, config like 'plainmount > (hd0,gpt2)' > always works > d) not GPT, multi-disk environment, disks map unpredictably: worst case, link > '(hd0,gpt2)' can randomly fail, but user can type manually in shell > e) cannot mount plain mode device in grub shell <- this is impossible, > plainmount > can always be called in shell. > > Best regards, > Maxim Fomin > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
