From nobody Fri Feb 18 02:19:27 2022 X-Original-To: freebsd-amd64@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AD8EA19C9212 for ; Fri, 18 Feb 2022 02:19:38 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K0Fky03Xyz4jDg for ; Fri, 18 Feb 2022 02:19:37 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 21I2JSgR095785 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Feb 2022 18:19:28 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 21I2JRTW095784; Thu, 17 Feb 2022 18:19:27 -0800 (PST) (envelope-from jmg) Date: Thu, 17 Feb 2022 18:19:27 -0800 From: John-Mark Gurney To: Georg Bege Cc: freebsd-amd64@FreeBSD.org Subject: Re: geli keyfile arguments / gpt partitions Message-ID: <20220218021927.GL97875@funkthat.com> Mail-Followup-To: Georg Bege , freebsd-amd64@FreeBSD.org References: <54f1aaaa-d4ed-1273-df9d-27cae3c1dc5f@bege.email> <20220214232955.GF97875@funkthat.com> <7c276e6d-d84a-e39d-fd4a-575fa850aeaa@bege.email> <20220217012447.GH97875@funkthat.com> List-Id: Porting FreeBSD to the AMD64 platform List-Archive: https://lists.freebsd.org/archives/freebsd-amd64 List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-amd64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 17 Feb 2022 18:19:28 -0800 (PST) X-Rspamd-Queue-Id: 4K0Fky03Xyz4jDg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-1.78 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.978]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-amd64]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Georg Bege wrote this message on Thu, Feb 17, 2022 at 11:02 +0100: > Hello again, > > ah I see - first I really didn't know that I can use "exec" command. > > Is this documented somewhere? At least I had trouble figuring out the > various possible loader.conf(8): exec Immediately executes a loader(8) command. This type of setting cannot be processed by programs other than loader(8), so its use should be avoided. Multiple instances of it will be processed independently. > schemes what geli__keyfile_* can be - this is somewhat opaque. From my understanding, load_geli does this mapping for you already... See: https://cgit.freebsd.org/src/blame/stand/common/module.c#n231 > Its correct, there is an example in geli(8) but I felt that Im lacking a > complete documentation for this. > > > In my setup Im simply booting via UEFI from a single ssd/partition which > only contains /boot ... nothing else. > > I'll defintly try what you have proposed, I first tried this via the > geli tunables above - this didnt really work out. > > > But I propably did it wrong, I tried to use an absolute path /dev/.... > but of course at that point - with only /boot and loader running, > > I dont have a working /dev at all yet. Correct, which is why you use the different syntax.. Loader does not use the same /dev syntax that the kernel uses... > Another issue I have, which I could however change - but I'd like to > read my 256b key from a partition and not from a file in a file system. I do not think that is possible w/o updating how loader handles things... But someone who knows loader better may have a solution... > So I simply dd' my key like /dev/ada0p3 (for example), I hoped that I > can do it this way. I think putting it on a FAT file system would likely be best and easiest. It won't require that much more space, as you can likely just create a 512k FAT file system to put the file on it. > Also if you know around the FreeBSD kernel / source maybe you can tell > me where  this is going on? Im quite fine with C, but Im lacking all the > details So part of this work is done in loader, and the source code for this is in src/stand. The geli code is at: https://cgit.freebsd.org/src/blame/sys/geom/eli/g_eli.c#n1249 > in order to understand where to find the right place in the sources. > > I had the feeling its somewhere in ./sys/geom/eli/g_eli.c ... or at > least around that where the parsing regarding the tunables is going on. So, again, I'd try to use the example I provided which was putting the following line in loader.conf: exec load_geli da0 disk1p3:/path/to/key.file But update disk1p3 to what ever lsdev from loader tells you to use... > Am 17.02.22 um 02:24 schrieb John-Mark Gurney: > > Georg Bege wrote this message on Thu, Feb 17, 2022 at 00:52 +0100: > >> thanks for your response - but this also doesn't help my situation. > >> > >> Most people didnt get this, I dont have an unecrypted / seperate root on > >> another disk. > >> > >> I dont want to... I'd like to keep the root on the same encrypted pool. :-) > >> > >> So Im investigating if and how I can access devices (eg. partitions) in > >> kernel-land which the kernel can read the key from. > > Ahh, rereading this, it sounds like you need to specify the key file > > differently. > > > > So, geli does support using preloaded keys by the loader.. you can use > > load_geli (loader(8) ) in the loader to preload keyfiles from the usb > > drive which the kernel will then use... The file should be able to be > > specified via :, and you can use lsdev to figure out > > what should be for your usb drive. Hopefully it will be > > consistent across boots. > > > > It appears (I have not used it myself), you can add an exec command to > > the loader.conf (loader.conf(8) ), so something like: > > exec load_geli da0 disk1p3:/path/to/key.file > > > > Hopefully this helps you. > > > > Let me know if this works, and I'll post this to the mailing list as well.. > > > > Or feel free to follow up w/ a complete walk through of your own... > > > >> Am 15.02.22 um 00:29 schrieb John-Mark Gurney: > >>> Georg Bege wrote this message on Tue, Feb 01, 2022 at 20:06 +0100: > >>>> Hello mailing list, > >>>> > >>>> Im trying to realize a specific encrypted setup on my FreeBSD machine at > >>>> home. > >>>> > >>>> For now I've a raidz2 pool, which did contain root - however it doesnt > >>>> boot anylonger. > >>>> > >>>> I have a dedicated SATA disk with UEFI boot code and /boot data, so this > >>>> works and I can bootup. > >>>> > >>>> What I wanted to do now is now encrypt the devices of the pool, > >>>> > >>>> which should work in general because I can boot the kernel and thus the > >>>> kernel should be able to decrypt the required disk devices. > >>>> > >>>> > >>>> My issue is now that if I find anything on google etc, all examples want > >>>> me to put the keyfile on /boot and then provide it as an argument like: > >>>> geli__keyfile0_name="/boot/encrypted.key" > >>>> > >>>> This is something I dont want to do, instead I'd prefer that I put the > >>>> keyfile data on a single gpt partition of an usb stick of my choice - > >>>> > >>>> I can reach this device whenever I boot up... however it seems I can not > >>>> provide a /dev/... device just like this as an argument. > >>>> > >>>> I dont even know if the kernel is able to read raw data from a gpt > >>>> partition... but well why not? It should be possible? > >>>> > >>>> > >>>> Has anyone a clue how to archive this or which arguments I need to provide? > >>> I wrote a custom rc.d script to handle this. > >>> > >>> The core is: > >>> cd / && > >>> for i in *.key; do > >>> geli attach -p -k "$i" "label/${i%.key}" > >>> geli attach -p -k "$i" "gpt/${i%.key}" > >>> done > >>> > >>> I now relize I could do a if [ -c ] before each so I don't get > >>> the error message, but I wrote this a LONG time ago, and it wasn't a > >>> big deal to [not] see the error messages on boot... > >>> > >>> and before the above, I have code that mounts the device w/ the keys on > >>> it.. > >>> > >>> the -p is necessary in addition to the -k: > >>> -k keyfile Specifies a file which contains the > >>> keyfile component of the User Key (or > >>> part of it). For more information see > >>> the description of the -K option for > >>> the init subcommand. > >>> > >>> -p Do not use a passphrase as a component > >>> of the User Key. Cannot be combined > >>> with the -j option. > >>> -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."