From nobody Thu Feb 17 10:02:19 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 06A9219CCB13 for ; Thu, 17 Feb 2022 10:02:48 +0000 (UTC) (envelope-from georg@bege.email) Received: from mail.unix.io (mail.unix.io [IPv6:2001:470:1f09:68::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jzr3q0mR2z4dMw for ; Thu, 17 Feb 2022 10:02:46 +0000 (UTC) (envelope-from georg@bege.email) Received: from mail.unix.io (localhost [127.0.0.1]) by mail.unix.io (Postfix) with ESMTP id 97705445E3; Thu, 17 Feb 2022 10:02:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bege.email; h=message-id :date:mime-version:subject:to:references:from:cc:in-reply-to :content-type:content-transfer-encoding; s=mail141202; bh=ScBf9U WdU+0aikvkbZ6pa4QCVWM=; b=y1QcZojIt4soQaMXsD3f7RwO9elG+7ufVQYIFF +E27OHMHcWA6Y1swyDriNOTWMNa4wcgI47XRcyuEjyBmClUFQMwaddqhD4tiByv2 PsSVwcF8cEnzDcW+vlDa1ZVu26mvEojZMVhTsp+ESh57PqgEVhIMjW2UyfVT3vbc BZCZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bege.email; h=message-id :date:mime-version:subject:to:references:from:cc:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail141202; b= nfaS7rYPbFlLgMilwomdZgv4QFF+0RmCWsDiknJUr+fklmF4HujDJs9/N4vXOp44 mLaYkyD6GypN/k9slKh/iMDgELbBSDav9XSKkPvzwAZeTmR+2JRy0f+4lqMp4nfX qxW7pp1e5QUorxqHCKsOlXUuC20sW4PCm0aoAqUC3kU= Received: from [192.168.171.2] (p5dcee62e.dip0.t-ipconnect.de [93.206.230.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mail.unix.io (Postfix) with ESMTPSA id E93EA444E9; Thu, 17 Feb 2022 10:02:26 +0000 (GMT) Message-ID: Date: Thu, 17 Feb 2022 11:02:19 +0100 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: geli keyfile arguments / gpt partitions Content-Language: en-US To: John-Mark Gurney References: <54f1aaaa-d4ed-1273-df9d-27cae3c1dc5f@bege.email> <20220214232955.GF97875@funkthat.com> <7c276e6d-d84a-e39d-fd4a-575fa850aeaa@bege.email> <20220217012447.GH97875@funkthat.com> From: Georg Bege Cc: freebsd-amd64@FreeBSD.org In-Reply-To: <20220217012447.GH97875@funkthat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Jzr3q0mR2z4dMw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bege.email header.s=mail141202 header.b=y1QcZojI; dmarc=none; spf=pass (mx1.freebsd.org: domain of georg@bege.email designates 2001:470:1f09:68::2 as permitted sender) smtp.mailfrom=georg@bege.email X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bege.email:s=mail141202]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bege.email]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bege.email:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-amd64]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[93.206.230.46:received] X-ThisMailContainsUnwantedMimeParts: N 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 schemes what geli__keyfile_* can be - this is somewhat opaque. 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. 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. So I simply dd' my key like /dev/ada0p3 (for example), I hoped that I can do it this way. 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 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. best regards, Georg 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. >>>