From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nF3uN-0000sg-Oo for mharc-grub-devel@gnu.org; Tue, 01 Feb 2022 19:54:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nF3tv-0000pm-4r for grub-devel@gnu.org; Tue, 01 Feb 2022 19:53:39 -0500 Received: from [2607:f8b0:4864:20::734] (port=38470 helo=mail-qk1-x734.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nF3tp-0003Gr-3P for grub-devel@gnu.org; Tue, 01 Feb 2022 19:53:31 -0500 Received: by mail-qk1-x734.google.com with SMTP id o12so16807040qke.5 for ; Tue, 01 Feb 2022 16:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficientek-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=rGTLsYxGTQ2Q5CzM1KnhtWRQ3p9WI83t/DfZpJW9ae4=; b=M7NgeTXUYsj8Kk0+8tOz0ut7oPpZlY8PcjqznDvNiqHZ4ANac1FLDr/YBjwpsfo6yz NpV4RftIYA/4ZMBPUPkAADWwpzibNhMKxhYK8arFQDqHTJ1Zxe9CkExeH0UqTJkiNIaB EpmLj5/zttgvIhsgexq4hFtYOWhBVRNu9PnU1t1lN9ZwiqK2412EB5EV7sBNSVOxqNgq Nt+Q9wA8dt2HCmktMQi2Nl0nfZ2X4Ulv54YKdQZ20DnD2bM6kP6ZpOuwwmFhZ7SZE0bE q7Ve/+mIN1bFaYLYqomU4+ILMCu3cP6sH+/yBCnln7R8uGJsChDqXkud67JMAMm8Tzp7 oFoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=rGTLsYxGTQ2Q5CzM1KnhtWRQ3p9WI83t/DfZpJW9ae4=; b=DDmCUDVJRm9ouJfRHp9S1kQWkV9M0E841LhbVsjnUEnJvQj/cNywX30JGc9LfA3d9W DzXG+ihZ08+qJHHp7Zi1zKMuWx+ikrzCTJ029HotH+egSolBy2HXv+oF1TNycJWG/1By Iy4WE9zoqYBCPwvqivLaz5BOwRrzJ2SoAc1pVVTbZDBxxoUOeB/S9DL+ghBzjJnfsi+f i45bWdufI9ppoli3buPglyldWc10R6dFdOOAYu/WjZED0BJDt7FfW6btG+4xURJ9NK/d qi24J1SmkFCXhE33lp3e/j1aHCXHF55alHd0+uzx2FC3kZpg7Cd1oeGFTm41MZEWTdr4 jqKw== X-Gm-Message-State: AOAM533P9I55pCq6E69el3y1jw3ccwk1Ddj0JrvjnqUkd5ipIsEJjoh9 Y8FNAa/Ravkz+LvK0KjuwmdWzef/y3obqg== X-Google-Smtp-Source: ABdhPJz+rd0jMGWX/GT3+W/TA8R8vGSxDtDunuVeb4apRLKE8/xcfreD3cqQOZXXS+KuZW7/9wYVog== X-Received: by 2002:a05:620a:348:: with SMTP id t8mr18899283qkm.628.1643763204703; Tue, 01 Feb 2022 16:53:24 -0800 (PST) Received: from crass-HP-ZBook-15-G2 (garza.riseup.net. [198.252.153.109]) by smtp.gmail.com with ESMTPSA id f22sm11636798qtb.1.2022.02.01.16.53.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Feb 2022 16:53:24 -0800 (PST) Date: Tue, 1 Feb 2022 18:51:06 -0600 From: Glenn Washburn To: Maxim Fomin Cc: The development of GNU GRUB Subject: Re: [PATCH 0/2] Support plain encryption mode. Message-ID: <20220201185106.4be9b679@crass-HP-ZBook-15-G2> In-Reply-To: References: <-gYg2fhNOHhD_BSgH0s5jno5SmqrQC7rpo6mu3cT1I0XzEv5SUsXeyONbFy4g_LouLwZSzn2s0dFhHvvVw9_HNpJPIRp1d3eZCBGXCJPD4g=@fomin.one> <20220131144018.7592f807@crass-HP-ZBook-15-G2> Reply-To: development@efficientek.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::734 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::734; envelope-from=development@efficientek.com; helo=mail-qk1-x734.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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: Wed, 02 Feb 2022 00:53:41 -0000 On Tue, 01 Feb 2022 15:48:01 +0000 Maxim Fomin wrote: > ------- 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 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