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.
