# No more PEFS on FreeBSD 13?



## rm1984 (Apr 15, 2021)

Hi guys,

is PEFS abandoned?

I just upgraded my FreeBSD box from 12.2 to 13.0, and PEFS works no more.
No way to load the "pefs" kernel module, no more "pefs-kmod" package available, and when I try to compile "pefs-kmod" from ports this is what I get:


```
===>  License BSD2CLAUSE accepted by the user
===>   pefs-kmod-2018.11.26 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by pefs-kmod-2018.11.26 for building
===>  Extracting for pefs-kmod-2018.11.26
=> SHA256 Checksum OK for pefs-2018-11-26.tar.gz.
===>  Patching for pefs-kmod-2018.11.26
===>  Applying FreeBSD patches for pefs-kmod-2018.11.26 from /usr/ports/sysutils/pefs-kmod/files
===>  Configuring for pefs-kmod-2018.11.26
===>  Building for pefs-kmod-2018.11.26
===> sys/modules/pefs (all)
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h
touch opt_global.h
Warning: Object directory not changed from original /usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26/sys/modules/pefs
cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I/usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26/sys/modules/pefs/../../ -include /usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26/sys/modules/pefs/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include     -MD  -MF.depend.pefs_subr.o -MTpefs_subr.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes -mno-avx  -std=iso9899:1999 -c /usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26/sys/modules/pefs/../../fs/pefs/pefs_subr.c -o pefs_subr.o
/usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26/sys/modules/pefs/../../fs/pefs/pefs_subr.c:249:21: error: too many arguments to function call, expected single argument 'vp', have 2 arguments
                        VOP_UNLOCK(ldvp, 0);
                        ~~~~~~~~~~       ^
./vnode_if.h:1145:21: note: 'VOP_UNLOCK' declared here
static __inline int VOP_UNLOCK(
                    ^
/usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26/sys/modules/pefs/../../fs/pefs/pefs_subr.c:254:18: error: too many arguments to function call, expected single argument 'vp', have 2 arguments
        VOP_UNLOCK(lvp, 0);
        ~~~~~~~~~~      ^
./vnode_if.h:1145:21: note: 'VOP_UNLOCK' declared here
static __inline int VOP_UNLOCK(
                    ^
/usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26/sys/modules/pefs/../../fs/pefs/pefs_subr.c:256:44: error: too many arguments to function call, expected 3, have 4
        error = vn_vptocnp(&nldvp, cred, encname, encname_len);
                ~~~~~~~~~~                        ^~~~~~~~~~~
/usr/src/sys/sys/vnode.h:681:5: note: 'vn_vptocnp' declared here
int     vn_vptocnp(struct vnode **vp, char *buf, size_t *buflen);
        ^
/usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26/sys/modules/pefs/../../fs/pefs/pefs_subr.c:383:23: error: use of undeclared identifier 'VI_DOOMED'
                if ((lvp->v_iflag & VI_DOOMED) != 0) {
                                    ^
4 errors generated.
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26/sys/modules/pefs
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/sysutils/pefs-kmod/work/pefs-2018-11-26
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/sysutils/pefs-kmod
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/pefs-kmod
```

It would be really sad if this project was abandoned... 
Thanks!


----------



## SirDice (Apr 15, 2021)

Contact the original developer, it will need to be fixed there. And I see you already did that: https://github.com/glk/pefs/issues/45

But also look at this: https://github.com/glk/pefs/issues/44
So I'm afraid the developer doesn't have time to fix it.


----------



## zirias@ (Apr 15, 2021)

Depending on the actual usecase, encrypted ZFS datasets should provide an alternative. But you'd need the `pam_zfs_key` module. It exists in OpenZFS, but I can't find it in my FreeBSD 13 installation. Does anyone know details?


----------



## facedebouc (Apr 15, 2021)

Zirias said:


> Depending on the actual usecase, encrypted ZFS datasets should provide an alternative. But you'd need the `pam_zfs_key` module. It exists in OpenZFS, but I can't find it in my FreeBSD 13 installation. Does anyone know details?


PEFS is filesystem agnostic. So encrypted ZFS is not an alternative.


----------



## facedebouc (Apr 15, 2021)

sysutils/fusefs-encfs could be an alternative.


----------



## zirias@ (Apr 15, 2021)

facedebouc said:


> PEFS is filesystem agnostic. So encrypted ZFS is not an alternative.


It could be, as I wrote, _depending on the usecase_. If the usecase is to have encrypted homes, and you're using ZFS, then it is.


facedebouc said:


> sysutils/fusefs-encfs could be an alternative.


Same logic as yours: PEFS is a kernel-level filesystem, so anything fusefs is not an alternative.


----------



## SirDice (Apr 15, 2021)

Also keep an eye on PR 254640.


----------



## T-Daemon (Apr 15, 2021)

Zirias said:


> Depending on the actual usecase, encrypted ZFS datasets should provide an alternative. But you'd need the `pam_zfs_key` module.



Can you elaborate? For what exactly do you need the pam module? I have on a 13.0-RELEASE test system encrypted datasets inclusive /usr/home/<user>, they work just fine. For the time being it's in an experimental state, I'm investigating the following implementation:



Zirias said:


> If the usecase is to have encrypted homes



I've been working on to encrypt per user home directories automatic when a user is added, where the login password is the encryption key, based on this blog:



			https://blogs.oracle.com/stw/encrypting-my-home-directory-on-zfs
		


which is based on



			https://blogs.oracle.com/solaris/user-home-directory-encryption-with-zfs-v2
		


The Solaris pam_zfs_key.so.1 module from the article seems to be the same, taking the name as base, with the pam_zfs_key.so module which comes with sysutils/openzfs, but I hadn't any success in my attempts so far to implement this in a per user home encryption with adduser(8), if it's possible at all.

Had you this use-case in mind, in which the module provides the possibility I'm trying to implement?


----------



## zirias@ (Apr 15, 2021)

I never tried anything there cause I don't have this usecase. But from what I understand, you need the PAM module to automatically decrypt the dataset for the user who logs in (and close it again when the session ends).


----------



## rm1984 (Apr 15, 2021)

Hi guys,
thanks for all the feedback.

In my case, I don't need to encrypt my whole home directory, but only some subdirs, so PEFS is the best working solution at the moment.

I wrote the developer (Gleb Kurtsou), and he kindly answered me soon after telling that he doesn't have so much time to spend on the project, and it will take him some weekends to fix the issues.
He'll be posting updates on the progress.

Fingers crossed!


----------



## SirDice (Apr 15, 2021)

Also chime in on the PR I referenced. It's the same error but on 14-CURRENT. If the source has been updated you'll need to talk to the port maintainer to get the port updated with the newer version. You can do that with that PR.


----------



## monwarez (Apr 15, 2021)

T-Daemon said:


> Can you elaborate? For what exactly do you need the pam module? I have on a 13.0-RELEASE test system encrypted datasets inclusive /usr/home/<user>, they work just fine. For the time being it's in an experimental state, I'm investigating the following implementation:


Is that with OpenZFS on root ? Last time I check, there was no support in the boot loader to support booting off a zfs pool that have an encrypted datasets.

For the OP: on a side note, if you look at freshports you can easily check if a port build for the next FreeBSD version. It is a good idea, especially for kernel driver to check before upgrading if they did not fail to build. If you cannot reverse the upgrade and want to access your file,
a solution would be to launch FreeBSD 12.0 on a VM, give it acces to the file (with NFS). In the VM use pefs to decrypt on another directory,
and then you could use sshfs to mount it back to the host, and of course in another directory.


----------



## T-Daemon (Apr 16, 2021)

monwarez said:


> Is that with OpenZFS on root ?


Yes it's base OpenZFS on root, but root is not encrypted here. Some datasets under zroot and zroot/usr/home, user accounts in particular, have encryption set on.



monwarez said:


> Last time I check, there was no support in the boot loader to support booting off a zfs pool that have an encrypted datasets.


As far as I know, currently that's still the case. 



monwarez said:


> On a side note, if you look at freshports you can easily check if a port build for the next FreeBSD version. It is a good idea, especially for kernel driver to check before upgrading if they did not fail to build.


Thanks for the tip. This is a test 13.0-RELEASE in a VM, upgraded from RC5, I had no active ports installed kernel modules at that time (sysutils/openzfs-kmod in my case).



monwarez said:


> If you cannot reverse the upgrade and want to access your file,


Being a test system there are no relevant files I might want to keep.



monwarez said:


> a solution would be to launch FreeBSD 12.0 on a VM, give it acces to the file (with NFS). In the VM *use* *pefs to decrypt* on another directory,
> and then you could use sshfs to mount it back to the host, and of course in another directory.


You misunderstood, I'm not using sysutils/pefs-kmod, OP does. I'm using and testing OpenZFS native encryption. Nevertheless thank you for taking the time to look into the matter.


----------



## T-Daemon (Apr 16, 2021)

Zirias said:


> But from what I understand, you need the PAM module to automatically decrypt the dataset for the user who logs in (and close it again when the session ends).


I couldn't find any information on this topic for FreeBSD. Do you know of any documentation on this subject?


----------



## hatchling (May 28, 2021)

Woah I wish I had seen this prior to upgrading to 13!!

PEFS is critical so now I need to figure out how to downgrade which I haven't had to do before. Oh no!


----------



## jb_fvwm2 (May 28, 2021)

mount from a v12 usb thumbdrive?  [ guessing ... ]


----------



## von_Gaden (Jun 7, 2021)

You can downgrade only if you haven't upgraded ZFS with `zpool upgrade <pool>`.
The downgrade is not so straightforward. You'll have to replace everything except /var, /usr/home and /tmp with the 12.2-RELEASE. If you need I can help you further.


----------



## T-Daemon (Jul 20, 2021)

Fix build for 13+ committed on 2021-07-19 into ports, main (latest) and branch 2021Q3. Packages available soon accordingly to build cycle of the branches.






						256956 – sysutils/pefs-kmod: Take maintainership, fix build on FreeBSD 13 & -current
					






					bugs.freebsd.org


----------

