Re: geli keyfile arguments / gpt partitions

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_<dev>_keyfile<num>_* 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 <devicename>:<path>, and you can use lsdev to figure out
> > what <devincename> 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_<device>_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 /<keydir> &&
> >>> 	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 <dev> ] 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."