From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nEvOG-0008HO-ED for mharc-grub-devel@gnu.org; Tue, 01 Feb 2022 10:48:24 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEvOC-0008Fk-QJ for grub-devel@gnu.org; Tue, 01 Feb 2022 10:48:16 -0500 Received: from mail-4317.proton.ch ([185.70.43.17]:11285) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEvOA-0000fw-6K for grub-devel@gnu.org; Tue, 01 Feb 2022 10:48:16 -0500 Date: Tue, 01 Feb 2022 15:48:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fomin.one; s=protonmail2; t=1643730484; bh=jjPQJ3n94Ulyd9k5P/Gc30n3JmZHsLAwic+amzo9Rc8=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: From:To:Cc; b=Z2IqbC6RU4j+IOU7EC5ENwZPMoc9bGD9kx0QXsLRUM3FQuvkP+z1/kS1zO1ax0HPO 9w++CIZ3B++Wuum7F8W3yCx/2mzrTzH4hc/MBX+EkjVFmHrHow9tykhHN1g/wI4+GU 6IFGPmkgi8aU1ygbKcwH1aVMTqlWZhpinidu1KcG9kPFIQqyX/6uq0zNfmUoyOABc/ wr0CSE9YR148HOqYWt2sLYnmgl6zFOjDC+JIeX33xRyZkKxMSt0jzxdVxJpY+Hl3UH I42AyW/zkEaDQhcDb7wENrfVRZ8ChmWlXqQGehLgUx5+Qsbvx8BLq5ZUhwue/kHNme DLtQ46q1xBmAg== To: "grub-devel@gnu.org" From: Maxim Fomin Reply-To: Maxim Fomin Subject: Re: [PATCH 0/2] Support plain encryption mode. Message-ID: In-Reply-To: <20220131144018.7592f807@crass-HP-ZBook-15-G2> References: <-gYg2fhNOHhD_BSgH0s5jno5SmqrQC7rpo6mu3cT1I0XzEv5SUsXeyONbFy4g_LouLwZSzn2s0dFhHvvVw9_HNpJPIRp1d3eZCBGXCJPD4g=@fomin.one> <20220131144018.7592f807@crass-HP-ZBook-15-G2> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.17; envelope-from=maxim@fomin.one; helo=mail-4317.proton.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 15:48:17 -0000 ------- Original Message ------- On Monday, January 31st, 2022 at 23:40, Glenn Washburn wrote: > On Sun, 30 Jan 2022 19:40:37 +0000 > > Maxim Fomin maxim@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 pat= ch > > > > (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. P= lainmount > > > > 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 par= tition. > > > > 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 orig= inal 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 li= mited is the ability to use UUID - currently only on GPT. If partition scheme doe= s not have UUID then UUID as a convenience feature cannot be supported - inconven= ient, but technically fair. I will take a look at MBR UUID and see whether they c= an be supported. Possible situations (under current implementaion) are follows: a) GPT disk, multi-disk environment, disks map unpredictably: can name part= itions by GPT UUID in config file/shell, no problem, ability to name by UUID ha= s value b) GPT disk, single disk environment: no problem, UUID feature has less val= ue b) not GPT, single disk environment: no problem, config like 'plainmount (h= d0,gpt2)' always works d) not GPT, multi-disk environment, disks map unpredictably: worst case, li= nk '(hd0,gpt2)' can randomly fail, but user can type manually in shell e) cannot mount plain mode device in grub shell <- this is impossible, plai= nmount can always be called in shell. Best regards, Maxim Fomin