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."
