Re: geli keyfile arguments / gpt partitions

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_<dev>_keyfile<num>_* 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 <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.
>>>